資料的順序性
（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小時的時間才能恢復過來
一般這個時候，只能操作臨時緊急擴容了，具體操作步驟和思路如下：
- 先修復consumer的問題，確保其恢復消費速度，然後將現有cnosumer都停掉
- 新建一個topic，partition是原來的10倍，臨時建立好原先10倍或者20倍的queue數量
- 然後寫一個臨時的分發資料的consumer程式，這個程式部署上去消費積壓的資料，消費之後不做耗時的處理，直接均勻輪詢寫入臨時建立好的10倍數量的queue
- 接著臨時徵用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的資料
- 這種做法相當於是臨時將queue資源和consumer資源擴大10倍，以正常的10倍速度來消費資料
- 等快速消費完積壓資料之後，得恢復原先部署架構，重新用原先的consumer機器來消費訊息
這裡我們假設再來第二個坑
假設你用的是rabbitmq，rabbitmq是可以設定過期時間的，就是TTL，如果訊息在queue中積壓超過一定的時間就會被rabbitmq給清理掉，這個資料就沒了。那這就是第二個坑了。這就不是說資料會大量積壓在mq裡，而是大量的資料會直接搞丟。
這個情況下，就不是說要增加consumer消費積壓的訊息，因為實際上沒啥積壓，而是丟了大量的訊息。我們可以採取一個方案，就是批量重導，這個我們之前線上也有類似的場景幹過。就是大量積壓的時候，我們當時就直接丟棄資料了，然後等過了高峰期以後，比如大家一起喝咖啡熬夜到晚上12點以後，使用者都睡覺了。
這個時候我們就開始寫程式，將丟失的那批資料，寫個臨時程式，一點一點的查出來，然後重新灌入mq裡面去，把白天丟的資料給他補回來。也只能是這樣了。
假設1萬個訂單積壓在mq裡面，沒有處理，其中1000個訂單都丟了，你只能手動寫程式把那1000個訂單給查出來，手動發到mq裡去再補一次
然後我們再來假設第三個坑
如果走的方式是訊息積壓在mq裡，那麼如果你很長時間都沒處理掉，此時導致mq都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執行的太慢了，你臨時寫程式，接入資料來消費，消費一個丟棄一個，都不要了，快速消費掉所有的訊息。然後走第二個方案，到了晚上再補資料！
更多系列文章
最後
後續會持續更新分散式知識，大家覺得不錯可以點個贊在關注下，以後還會分享更多文章！