檢測訊息丟失的方法

用訊息佇列最尷尬的情況不是丟訊息，而是丟了訊息還不知道，因此，我們需要設計一套機制來監控訊息是否有丟失，

根據專案的成熟程度，一般有兩種方式來檢測：

我們可以在Producer端發出的每一條訊息附加一個連續遞增的序號，然后在Consumer端檢測這個序號的連續性，如果沒有訊息丟失，Consumer收到的訊息的序號必然是連續遞增的，如果檢測到序號不連續，那么就是丟訊息了，還可以通過缺失的序號來確定丟失的是哪一條訊息，

針對這種檢測方法，有3條建議：

像Kafka和RocketMQ這樣的訊息佇列，它不保證訊息在Topic上的嚴格順序，只能保證訊息在磁區（佇列）上是有序的，所以我們在發訊息的時候必須要指定磁區，并且每個磁區單獨檢測訊息序號的連續性，
如果系統中有多個Producer實體，并且不好協調多個Producer之間的發送順序，那么也需要針對每個Producer分別生成各自的訊息序號，并且需要附加上Producer標識，在Consumer端按照每個Producer分別來檢測序號的連續性，
Consumer實體的數量最好和磁區數量一致，做到Consumer和磁區一一對應，這樣比較方便在Consumer內檢測訊息序號的連續性，

訊息可靠傳遞

一條訊息從生產到消費完成的程序，可以分為三個階段：

在生產階段，訊息佇列最常用的是請求-確認機制，來保證訊息的可靠傳遞：當代碼呼叫發訊息方法時，訊息佇列的客戶端會把訊息發送到Broker，Broker收到訊息后，會給客戶端回傳一個確認回應，表示訊息已經收到了，

只要Producer收到了Broker的確認回應，就可以保證訊息在生產階段不會丟失，有的訊息佇列會在長時間沒有收到發送確認回應后，自動重試，如果重試再失敗，就會以回傳值或者例外的方式告知用戶，

在存盤階段正常情況下，只要Broker在正常運行，就不會出現丟失訊息的問題，但是如果Broker出現了故障，還是有可能會丟訊息，

如果對訊息的可靠性要求非常高，可以通過配置Broker引數來避免因為宕機丟訊息，

如果Broker是由多個節點組成的集群，那么需要將Broker集群配置成：至少將訊息發送到2個以上的節點后，再給客戶端回復發送確認回應，

消費階段采用和生產階段類似的請求-確認機制來保證訊息的可靠傳遞，客戶端從Broker拉取訊息后，執行用戶的消費業務邏輯，成功后，才會給Broker發送消費確認回應，

如果Borker沒有收到消費確認回應，下次拉訊息時還會回傳同一條訊息，確保訊息不回在網路傳輸程序中丟失，也不會因為客戶端在執行消費邏輯中出錯導致丟失，

我們需要注意，不要在收到訊息后就立即發送消費確認，而是應該在執行完所有消費業務邏輯之后，再發送消費確認，

　　　　作者：李潘　　　　出處：http://wing011203.cnblogs.com/ 　　　　本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/546253.html