分佈式消息隊列：如何保證消息的順序性

數據的順序性

（1）rabbitmq保證數據的順序性

若是存在多個消費者，那麼就讓每一個消費者對應一個queue，而後把要發送 的數據全都放到一個queue，這樣就能保證全部的數據只到達一個消費者從而保證每一個數據到達數據庫都是順序的。
rabbitmq：拆分多個queue，每一個queue一個consumer，就是多一些queue而已，確實是麻煩點；或者就一個queue可是對應一個consumer，而後這個consumer內部用內存隊列作排隊，而後分發給底層不一樣的worker來處理

（2）kafka保證數據的順序性

kafka 寫入partion時指定一個key，列如訂單id，那麼消費者從partion中取出數據的時候確定是有序的，當開啓多個線程的時候可能致使數據不一致，這時候就須要內存隊列，將相同的hash過的數據放在一個內存隊列裏，這樣就能保證一條線程對應一個內存隊列的數據寫入數據庫的時候順序性的，從而能夠開啓多條線程對應多個內存隊列

kafka：一個topic，一個partition，一個consumer，內部單線程消費，寫N個內存queue，而後N個線程分別消費一個內存queue便可

MQ積壓幾百萬條數據怎麼辦？

這個是咱們真實遇到過的一個場景，確實是線上故障了，這個時候要否則就是修復consumer的問題，讓他恢復消費速度，而後傻傻的等待幾個小時消費完畢。這個確定不能在面試的時候說吧。

一個消費者一秒是1000條，一秒3個消費者是3000條，一分鐘是18萬條，1000多萬條

因此若是你積壓了幾百萬到上千萬的數據，即便消費者恢復了，也須要大概1小時的時間才能恢復過來

通常這個時候，只能操做臨時緊急擴容了，具體操做步驟和思路以下：

1. 先修復consumer的問題，確保其恢復消費速度，而後將現有cnosumer都停掉
2. 新建一個topic，partition是原來的10倍，臨時創建好原先10倍或者20倍的queue數量
3. 而後寫一個臨時的分發數據的consumer程序，這個程序部署上去消費積壓的數據，消費以後不作耗時的處理，直接均勻輪詢寫入臨時創建好的10倍數量的queue
4. 接着臨時徵用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的數據
5. 這種作法至關因而臨時將queue資源和consumer資源擴大10倍，以正常的10倍速度來消費數據
6. 等快速消費完積壓數據以後，得恢復原先部署架構，從新用原先的consumer機器來消費消息

這裏咱們假設再來第二個坑

假設你用的是rabbitmq，rabbitmq是能夠設置過時時間的，就是TTL，若是消息在queue中積壓超過必定的時間就會被rabbitmq給清理掉，這個數據就沒了。那這就是第二個坑了。這就不是說數據會大量積壓在mq裏，而是大量的數據會直接搞丟。

這個狀況下，就不是說要增長consumer消費積壓的消息，由於實際上沒啥積壓，而是丟了大量的消息。咱們能夠採起一個方案，就是批量重導，這個咱們以前線上也有相似的場景幹過。就是大量積壓的時候，咱們當時就直接丟棄數據了，而後等過了高峯期之後，好比你們一塊兒喝咖啡熬夜到晚上12點之後，用戶都睡覺了。

這個時候咱們就開始寫程序，將丟失的那批數據，寫個臨時程序，一點一點的查出來，而後從新灌入mq裏面去，把白天丟的數據給他補回來。也只能是這樣了。

假設1萬個訂單積壓在mq裏面，沒有處理，其中1000個訂單都丟了，你只能手動寫程序把那1000個訂單給查出來，手動發到mq裏去再補一次

而後咱們再來假設第三個坑

若是走的方式是消息積壓在mq裏，那麼若是你很長時間都沒處理掉，此時致使mq都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執行的太慢了，你臨時寫程序，接入數據來消費，消費一個丟棄一個，都不要了，快速消費掉全部的消息。而後走第二個方案，到了晚上再補數據！

更多系列文章

分佈式消息隊列：如何保證消息隊列的高可用

分佈式消息隊列：如何保證消息不被重複消費

分佈式消息隊列：如何保證消息的可靠性傳輸

分佈式消息隊列：如何保證消息的順序性

最後

後續會持續更新分佈式知識，你們以爲不錯能夠點個贊在關注下，之後還會分享更多文章！