一、訊息重複現象
在 mqtt 協議中，給出了三種傳遞訊息時能夠提供的服務質量標準：
at most once:最多一次，這種情況會丟失部分資料，一般日誌收集這種對資料不嚴格的可以使用
at least once:最少一次，這種會導致一條訊息重**送
exactly once:正好一次，一條訊息只會被消費一次
rocketmq,rabbit mq,kafka都是使用的at least once，雖然訊息會重複，但不會丟失。不使用exactly once這種呢，是因為這種每次傳送前傳送都要檢查這條訊息是否已成功傳送了，大大降低了mq的效能。
二、解決方案
那訊息重複了，該如何解決呢？一般都是在消費端保證冪等性來解決。
冪等：f(f(x))=f(x),執行多次和執行一次的結果是相同的，這種我們稱之為冪等的。
比如現在有個需求：給賬戶a的餘額增加100。
方案一：通過唯一約束控制
1.資料庫唯一索引：
流水表中交易訂單號和賬戶建立唯一索引，重複insert的時候違反唯一性，所以只會成功執行一次。
2.redis的setnx
redis中有這個key就不能重複操作
方案二：設定前提條件
1.資料庫查詢
加分布式鎖，然後查詢有沒有該訂單號的流水，沒有則可以插入。
2.資料庫版本號
查詢出當前記錄以及其中的版本號，更新的時候根據版本號來更新。
方案三：全域性id
生產者給資料增加乙個全域性id，消費端去查詢這個id有沒有消費過，沒有則進行處理。
五 如何處理訊息的重複消費
1at most once 至多一次 乙個訊息只被消費一次，不管是否成功，允許丟失一部分訊息。2at least once至少一次 一條訊息會被重複消費 3exactly once恰好一次 一條訊息只被處理一次，且必須成功，不能夠失敗 大部分訊息佇列都是符合 at least once,如rabbi...
handler是如何處理訊息
在handler機制中，同一執行緒中的多個handler是如何將訊息傳送給對應的handler物件去處理的呢？let s rtfsc 先看看handler的使用 class mainactivity start class handler1 handler class handler2 handle...
BizTalk Server 如何處理大訊息
什麼是大訊息？遺憾的是，此問題的答案不而直接與特定的訊息大小，繫結，取決於你的 microsoft 的特定瓶頸 biztalk server 系統。與大訊息關聯的問題可分為以下幾類 影響處理大訊息的因素 原始訊息大小 訊息格式以及訊息的處理型別都會影響 biztalk server 處理大訊息的方式...