網(wǎng)上有很多關(guān)于pos機(jī)怎么重啟,訂單超時怎么處理的知識，也有很多人為大家解答關(guān)于pos機(jī)怎么重啟的問題，今天pos機(jī)之家(www.bulldancerbisonranch.com)為大家整理了關(guān)于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
pos機(jī)怎么重啟
簡介： 描述業(yè)務(wù)常見的訂單超時處理的幾種方案及分析
作者 | 黃曉萌(學(xué)仁)
來源 | 阿里開發(fā)者公眾號
背景在企業(yè)的商業(yè)活動中，訂單是指交易雙方的產(chǎn)品或服務(wù)交易意向。交易下單負(fù)責(zé)創(chuàng)建這個交易雙方的產(chǎn)品或服務(wù)交易意向，有了這個意向后，買方可以付款，賣方可以發(fā)貨。
在電商場景下，買賣雙方?jīng)]有面對面交易，許多情況下需要通過超時處理自動關(guān)閉訂單，下面是一個訂單的流程：
如上圖所示，一個訂單流程中有許多環(huán)節(jié)要用到超時處理，包括但不限于：
買家超時未付款：比如超過15分鐘沒有支付，訂單自動取消。商家超時未發(fā)貨：比如商家超過1個月沒發(fā)貨，訂單自動取消。買家超時未收貨：比如商家發(fā)貨后，買家沒有在14天內(nèi)點擊確認(rèn)收貨，則系統(tǒng)默認(rèn)自動收貨。1. JDK自帶的延時隊列JDK中提供了一種延遲隊列數(shù)據(jù)結(jié)構(gòu)DelayQueue，其本質(zhì)是封裝了PriorityQueue，可以把元素進(jìn)行排序。
把訂單插入DelayQueue中，以超時時間作為排序條件，將訂單按照超時時間從小到大排序。起一個線程不停輪詢隊列的頭部，如果訂單的超時時間到了，就出隊進(jìn)行超時處理，并更新訂單狀態(tài)到數(shù)據(jù)庫中。為了防止機(jī)器重啟導(dǎo)致內(nèi)存中的DelayQueue數(shù)據(jù)丟失，每次機(jī)器啟動的時候，需要從數(shù)據(jù)庫中初始化未結(jié)束的訂單，加入到DelayQueue中。優(yōu)點：簡單，不需要借助其他第三方組件，成本低。缺點：所有超時處理訂單都要加入到DelayQueue中，占用內(nèi)存大。沒法做到分布式處理，只能在集群中選一臺leader專門處理，效率低。不適合訂單量比較大的場景。2. RabbitMQ的延時消息RabbitMQ的延時消息主要有兩個解決方案：
RabbitMQ Delayed Message Plugin消息的TTL+死信ExchangeRabbitMQ Delayed Message Plugin是官方提供的延時消息插件，雖然使用起來比較方便，但是不是高可用的，如果節(jié)點掛了會導(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解決方案，先要了解兩個概念：
TTL：即消息的存活時間。RabbitMQ可以對隊列和消息分別設(shè)置TTL，如果對隊列設(shè)置，則隊列中所有的消息都具有相同的過期時間。超過了這個時間，我們認(rèn)為這個消息就死了，稱之為死信。死信Exchange（DLX）：一個消息在滿足以下條件會進(jìn)入死信交換機(jī)一個消息被Consumer拒收了，并且reject方法的參數(shù)里requeue是false。也就是說不會被再次放在隊列里，被其他消費(fèi)者使用。
TTL到期的消息。
隊列滿了被丟棄的消息。
一個延時消息的流程如下圖：
定義一個BizQueue，用來接收死信消息，并進(jìn)行業(yè)務(wù)消費(fèi)。定義一個死信交換機(jī)(DLXExchange)，綁定BizQueue，接收延時隊列的消息，并轉(zhuǎn)發(fā)給BizQueue。定義一組延時隊列DelayQueue_xx，分別配置不同的TTL，用來處理固定延時5s、10s、30s等延時等級，并綁定到DLXExchange。定義DelayExchange，用來接收業(yè)務(wù)發(fā)過來的延時消息，并根據(jù)延時時間轉(zhuǎn)發(fā)到不同的延時隊列中。優(yōu)點：可以支持海量延時消息，支持分布式處理。缺點：不靈活，只能支持固定延時等級。
使用復(fù)雜，要配置一堆延時隊列。
3. RocketMQ的定時消息RocketMQ支持任意秒級的定時消息，如下圖所示
使用門檻低，只需要在發(fā)送消息的時候設(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è)置延時時間 .setDeliveryTimestamp(deliverTimeStamp) //消息體 .setBody("messageBody".getBytes()) .build();SendReceipt sendReceipt = producer.send(message);System.out.println(sendReceipt.getMessageId());
RocketMQ的定時消息是如何實現(xiàn)的呢？
在RocketMQ中，使用了經(jīng)典的時間輪算法。通過TimerWheel來描述時間輪不同的時刻，通過TimerLog來記錄不同時刻的消息。
TimerWheel中的每一格代表著一個時刻，同時會有一個firstPos指向這個刻度下所有定時消息的首條TimerLog記錄的地址，一個lastPos指向這個刻度下所有定時消息最后一條TimerLog的記錄的地址。并且，對于所處于同一個刻度的的消息，其TimerLog會通過prevPos串聯(lián)成一個鏈表。
當(dāng)需要新增一條記錄的時候，例如現(xiàn)在我們要新增一個 “1-4”。那么就將新記錄的 prevPos 指向當(dāng)前的 lastPos，即 “1-3”，然后修改 lastPos 指向 “1-4”。這樣就將同一個刻度上面的 TimerLog 記錄全都串起來了。
優(yōu)點
精度高，支持任意時刻。使用門檻低，和使用普通消息一樣。缺點
使用限制：定時時長最大值24小時。成本高：每個訂單需要新增一個定時消息，且不會馬上消費(fèi)，給MQ帶來很大的存儲成本。同一個時刻大量消息會導(dǎo)致消息延遲：定時消息的實現(xiàn)邏輯需要先經(jīng)過定時存儲等待觸發(fā)，定時時間到達(dá)后才會被投遞給消費(fèi)者。因此，如果將大量定時消息的定時時間設(shè)置為同一時刻，則到達(dá)該時刻后會有大量消息同時需要被處理，會造成系統(tǒng)壓力過大，導(dǎo)致消息分發(fā)延遲，影響定時精度。點擊查看原文，獲取更多福利！
https://developer.aliyun.com/article/1161311?utm_content=g_1000368355
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。
以上就是關(guān)于pos機(jī)怎么重啟,訂單超時怎么處理的知識，后面我們會繼續(xù)為大家整理關(guān)于pos機(jī)怎么重啟的知識，希望能夠幫助到大家！
