網(wǎng)上有很多關(guān)于pos機(jī)怎么重啟,訂單超時(shí)怎么處理的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)怎么重啟的問題，今天pos機(jī)之家(m.51zrwd.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來看下吧!

本文目錄一覽：

1、pos機(jī)怎么重啟

pos機(jī)怎么重啟

簡(jiǎn)介： 描述業(yè)務(wù)常見的訂單超時(shí)處理的幾種方案及分析

作者 | 黃曉萌(學(xué)仁)

來源 | 阿里開發(fā)者公眾號(hào)

背景

在企業(yè)的商業(yè)活動(dòng)中，訂單是指交易雙方的產(chǎn)品或服務(wù)交易意向。交易下單負(fù)責(zé)創(chuàng)建這個(gè)交易雙方的產(chǎn)品或服務(wù)交易意向，有了這個(gè)意向后，買方可以付款，賣方可以發(fā)貨。

在電商場(chǎng)景下，買賣雙方?jīng)]有面對(duì)面交易，許多情況下需要通過超時(shí)處理自動(dòng)關(guān)閉訂單，下面是一個(gè)訂單的流程：

如上圖所示，一個(gè)訂單流程中有許多環(huán)節(jié)要用到超時(shí)處理，包括但不限于：

買家超時(shí)未付款：比如超過15分鐘沒有支付，訂單自動(dòng)取消。商家超時(shí)未發(fā)貨：比如商家超過1個(gè)月沒發(fā)貨，訂單自動(dòng)取消。買家超時(shí)未收貨：比如商家發(fā)貨后，買家沒有在14天內(nèi)點(diǎn)擊確認(rèn)收貨，則系統(tǒng)默認(rèn)自動(dòng)收貨。1. JDK自帶的延時(shí)隊(duì)列

JDK中提供了一種延遲隊(duì)列數(shù)據(jù)結(jié)構(gòu)DelayQueue，其本質(zhì)是封裝了PriorityQueue，可以把元素進(jìn)行排序。

把訂單插入DelayQueue中，以超時(shí)時(shí)間作為排序條件，將訂單按照超時(shí)時(shí)間從小到大排序。起一個(gè)線程不停輪詢隊(duì)列的頭部，如果訂單的超時(shí)時(shí)間到了，就出隊(duì)進(jìn)行超時(shí)處理，并更新訂單狀態(tài)到數(shù)據(jù)庫中。為了防止機(jī)器重啟導(dǎo)致內(nèi)存中的DelayQueue數(shù)據(jù)丟失，每次機(jī)器啟動(dòng)的時(shí)候，需要從數(shù)據(jù)庫中初始化未結(jié)束的訂單，加入到DelayQueue中。優(yōu)點(diǎn)：簡(jiǎn)單，不需要借助其他第三方組件，成本低。缺點(diǎn)：所有超時(shí)處理訂單都要加入到DelayQueue中，占用內(nèi)存大。沒法做到分布式處理，只能在集群中選一臺(tái)leader專門處理，效率低。不適合訂單量比較大的場(chǎng)景。2. RabbitMQ的延時(shí)消息

RabbitMQ的延時(shí)消息主要有兩個(gè)解決方案：

RabbitMQ Delayed Message Plugin消息的TTL+死信Exchange

RabbitMQ Delayed Message Plugin是官方提供的延時(shí)消息插件，雖然使用起來比較方便，但是不是高可用的，如果節(jié)點(diǎn)掛了會(huì)導(dǎo)致消息丟失。引用官網(wǎng)原文：

Delayed messages are stored in a Mnesia table (also see Limitations below) with a single disk replica on the current node. They will survive a node restart. While timer(s) that triggered scheduled delivery are not persisted, it will be re-initialised during plugin activation on node start. Obviously, only having one copy of a scheduled message in a cluster means that losing that node or disabling the plugin on it will lose the messages residing on that node.

消息的TTL+死信Exchange解決方案，先要了解兩個(gè)概念：

TTL：即消息的存活時(shí)間。RabbitMQ可以對(duì)隊(duì)列和消息分別設(shè)置TTL，如果對(duì)隊(duì)列設(shè)置，則隊(duì)列中所有的消息都具有相同的過期時(shí)間。超過了這個(gè)時(shí)間，我們認(rèn)為這個(gè)消息就死了，稱之為死信。死信Exchange（DLX）：一個(gè)消息在滿足以下條件會(huì)進(jìn)入死信交換機(jī)

一個(gè)消息被Consumer拒收了，并且reject方法的參數(shù)里requeue是false。也就是說不會(huì)被再次放在隊(duì)列里，被其他消費(fèi)者使用。

TTL到期的消息。

隊(duì)列滿了被丟棄的消息。

一個(gè)延時(shí)消息的流程如下圖：

定義一個(gè)BizQueue，用來接收死信消息，并進(jìn)行業(yè)務(wù)消費(fèi)。定義一個(gè)死信交換機(jī)(DLXExchange)，綁定BizQueue，接收延時(shí)隊(duì)列的消息，并轉(zhuǎn)發(fā)給BizQueue。定義一組延時(shí)隊(duì)列DelayQueue_xx，分別配置不同的TTL，用來處理固定延時(shí)5s、10s、30s等延時(shí)等級(jí)，并綁定到DLXExchange。定義DelayExchange，用來接收業(yè)務(wù)發(fā)過來的延時(shí)消息，并根據(jù)延時(shí)時(shí)間轉(zhuǎn)發(fā)到不同的延時(shí)隊(duì)列中。優(yōu)點(diǎn)：可以支持海量延時(shí)消息，支持分布式處理。缺點(diǎn)：

不靈活，只能支持固定延時(shí)等級(jí)。

使用復(fù)雜，要配置一堆延時(shí)隊(duì)列。

3. RocketMQ的定時(shí)消息

RocketMQ支持任意秒級(jí)的定時(shí)消息，如下圖所示

使用門檻低，只需要在發(fā)送消息的時(shí)候設(shè)置延時(shí)時(shí)間即可，以java代碼為例：

MessageBuilder messageBuilder = null;Long deliverTimeStamp = System.currentTimeMillis() + 10L * 60 * 1000; //延遲10分鐘message message = messageBuilder.setTopic("topic") //設(shè)置消息索引鍵，可根據(jù)關(guān)鍵字精確查找某條消息。 .setKeys("messageKey") //設(shè)置消息Tag，用于消費(fèi)端根據(jù)指定Tag過濾消息。 .setTag("messageTag") //設(shè)置延時(shí)時(shí)間 .setDeliveryTimestamp(deliverTimeStamp) //消息體 .setBody("messageBody".getBytes()) .build();SendReceipt sendReceipt = producer.send(message);System.out.println(sendReceipt.getMessageId());

RocketMQ的定時(shí)消息是如何實(shí)現(xiàn)的呢？

在RocketMQ中，使用了經(jīng)典的時(shí)間輪算法。通過TimerWheel來描述時(shí)間輪不同的時(shí)刻，通過TimerLog來記錄不同時(shí)刻的消息。

TimerWheel中的每一格代表著一個(gè)時(shí)刻，同時(shí)會(huì)有一個(gè)firstPos指向這個(gè)刻度下所有定時(shí)消息的首條TimerLog記錄的地址，一個(gè)lastPos指向這個(gè)刻度下所有定時(shí)消息最后一條TimerLog的記錄的地址。并且，對(duì)于所處于同一個(gè)刻度的的消息，其TimerLog會(huì)通過prevPos串聯(lián)成一個(gè)鏈表。

當(dāng)需要新增一條記錄的時(shí)候，例如現(xiàn)在我們要新增一個(gè) “1-4”。那么就將新記錄的 prevPos 指向當(dāng)前的 lastPos，即 “1-3”，然后修改 lastPos 指向 “1-4”。這樣就將同一個(gè)刻度上面的 TimerLog 記錄全都串起來了。

優(yōu)點(diǎn)

精度高，支持任意時(shí)刻。使用門檻低，和使用普通消息一樣。

缺點(diǎn)

使用限制：定時(shí)時(shí)長(zhǎng)最大值24小時(shí)。成本高：每個(gè)訂單需要新增一個(gè)定時(shí)消息，且不會(huì)馬上消費(fèi)，給MQ帶來很大的存儲(chǔ)成本。同一個(gè)時(shí)刻大量消息會(huì)導(dǎo)致消息延遲：定時(shí)消息的實(shí)現(xiàn)邏輯需要先經(jīng)過定時(shí)存儲(chǔ)等待觸發(fā)，定時(shí)時(shí)間到達(dá)后才會(huì)被投遞給消費(fèi)者。因此，如果將大量定時(shí)消息的定時(shí)時(shí)間設(shè)置為同一時(shí)刻，則到達(dá)該時(shí)刻后會(huì)有大量消息同時(shí)需要被處理，會(huì)造成系統(tǒng)壓力過大，導(dǎo)致消息分發(fā)延遲，影響定時(shí)精度。

點(diǎn)擊查看原文，獲取更多福利！

https://developer.aliyun.com/article/1161311?utm_content=g_1000368355

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

以上就是關(guān)于pos機(jī)怎么重啟,訂單超時(shí)怎么處理的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)怎么重啟的知識(shí)，希望能夠幫助到大家！