pos機怎么重啟

新聞資訊2 | 2023-07-23 15:11 | 投稿人：pos機之家

網上有很多關于pos機怎么重啟,訂單超時怎么處理的知識，也有很多人為大家解答關于pos機怎么重啟的問題，今天pos機之家(www.www690aa.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機怎么重啟

pos機怎么重啟

簡介：描述業務常見的訂單超時處理的幾種方案及分析

作者 | 黃曉萌(學仁)

來源 | 阿里開發者公眾號

背景

在企業的商業活動中，訂單是指交易雙方的產品或服務交易意向。交易下單負責創建這個交易雙方的產品或服務交易意向，有了這個意向后，買方可以付款，賣方可以發貨。

在電商場景下，買賣雙方沒有面對面交易，許多情況下需要通過超時處理自動關閉訂單，下面是一個訂單的流程：

如上圖所示，一個訂單流程中有許多環節要用到超時處理，包括但不限于：

買家超時未付款：比如超過15分鐘沒有支付，訂單自動取消。商家超時未發貨：比如商家超過1個月沒發貨，訂單自動取消。買家超時未收貨：比如商家發貨后，買家沒有在14天內點擊確認收貨，則系統默認自動收貨。1. JDK自帶的延時隊列

JDK中提供了一種延遲隊列數據結構DelayQueue，其本質是封裝了PriorityQueue，可以把元素進行排序。

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

RabbitMQ的延時消息主要有兩個解決方案：

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

RabbitMQ Delayed Message Plugin是官方提供的延時消息插件，雖然使用起來比較方便，但是不是高可用的，如果節點掛了會導致消息丟失。引用官網原文：

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可以對隊列和消息分別設置TTL，如果對隊列設置，則隊列中所有的消息都具有相同的過期時間。超過了這個時間，我們認為這個消息就死了，稱之為死信。死信Exchange（DLX）：一個消息在滿足以下條件會進入死信交換機

一個消息被Consumer拒收了，并且reject方法的參數里requeue是false。也就是說不會被再次放在隊列里，被其他消費者使用。

TTL到期的消息。

隊列滿了被丟棄的消息。

一個延時消息的流程如下圖：

定義一個BizQueue，用來接收死信消息，并進行業務消費。定義一個死信交換機(DLXExchange)，綁定BizQueue，接收延時隊列的消息，并轉發給BizQueue。定義一組延時隊列DelayQueue_xx，分別配置不同的TTL，用來處理固定延時5s、10s、30s等延時等級，并綁定到DLXExchange。定義DelayExchange，用來接收業務發過來的延時消息，并根據延時時間轉發到不同的延時隊列中。優點：可以支持海量延時消息，支持分布式處理。缺點：

不靈活，只能支持固定延時等級。

使用復雜，要配置一堆延時隊列。

3. RocketMQ的定時消息

RocketMQ支持任意秒級的定時消息，如下圖所示

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

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

RocketMQ的定時消息是如何實現的呢？

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

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

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

優點

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

缺點

使用限制：定時時長最大值24小時。成本高：每個訂單需要新增一個定時消息，且不會馬上消費，給MQ帶來很大的存儲成本。同一個時刻大量消息會導致消息延遲：定時消息的實現邏輯需要先經過定時存儲等待觸發，定時時間到達后才會被投遞給消費者。因此，如果將大量定時消息的定時時間設置為同一時刻，則到達該時刻后會有大量消息同時需要被處理，會造成系統壓力過大，導致消息分發延遲，影響定時精度。

點擊查看原文，獲取更多福利！

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

以上就是關于pos機怎么重啟,訂單超時怎么處理的知識，后面我們會繼續為大家整理關于pos機怎么重啟的知識，希望能夠幫助到大家！