mq 提供一致性保證又分為兩個方面。發訊息時我們如何確保業務操作和發訊息是一致的，也就是不能出現業務操作成功訊息未發出或者訊息發出了但是業務並沒有成功的情況。舉例來說，支付服務使用訊息通知出票服務，那麼不能出現支付成功，但是訊息沒有發出，這會引起使用者投訴；但是也不能出現支付未成功，但是訊息發出最後出票了，這會導致公司損失。總結一下就是發訊息和業務需要有事務保證。一致性的另一端是消費者，比如消費者臨時出錯或網路故障，我們如何確保訊息最終被處理了。那麼我們通過消費 ack 和重試來達到最終一致性。
三、利用資料庫事務解決一致性問題
提到一致性，大家肯定就想到事務，而一提到事務，肯定就想到關係型資料庫，那麼我們是不是可以借助關係型 db 裡久經考驗的事務來實現這個一致性呢。我們以 mysql 為例，對於 mysql 中同乙個例項裡面的 db，如果共享相同的 connection 的話是可以在同乙個事務裡的。以下圖為例，我們有乙個 mysql 例項監聽在 3306 埠上，然後該例項上有 a，b 兩個 db，那麼下面的偽**是可以跑在同乙個事務裡的
有了這層保證，我們就可以透明的實現業務操作和訊息傳送在同乙個事務裡了，首先我們在公司所有 mysql 例項裡初始化出乙個 message db，這個可以放到自動化流程中（據說在去哪兒由運維團隊完成），對應用透明。然後我們只要將發訊息與業務操作放到同乙個 db 事務裡即可。
我們來看乙個實際的場景，在支付場景中，支付成功後我們需要插入一條支付流水，並且傳送一條支付完成的訊息通知其他系統。那麼這裡插入支付流水和傳送訊息就需要是一致的，任何一步沒有成功最後都會導致問題。那麼就有下面的**
上面的**可以用下面的偽**解釋
1、begin tx 開啟本地事務
2、do work 執行業務操作
3、insert message 向同例項訊息庫插入訊息
4、end tx 事務提交
5、send message 網路向 server 傳送訊息
6、reponse server 回應訊息
7、delete message 如果 server 回覆成功則刪除訊息
8、scan messages 補償任務掃瞄未傳送訊息
9、send message 補償任務補償訊息
10、delete messages 補償任務刪除補償成功的訊息
MQ一致性訊息服務 訊息冪等
mq一致性訊息服務 訊息冪等 一 緣起 mq訊息必達，架構上有兩個核心設計點 1 訊息落地 2 訊息超時 重傳 確認 再次回顧訊息匯流排核心架構，它由 傳送端 服務端 固化儲存 接收端 四大部分組成。為保證訊息的可達性，超時 重傳 確認機制可能導致訊息匯流排 或者業務方收到重複的訊息，從而對業務產生...
資料庫一致性
資料庫一致性 database consistency 是指事務執行的結果必須是使資料庫從乙個一致性狀態變到另乙個一致性狀態。保證資料庫一致性是指當事務完成時，必須使所有資料都具有一致的狀態。在關係型資料庫中，所有的規則必須應用到事務的修改上，以便維護所有資料的完整性。保證資料庫的一致性是資料庫管理...
資料庫的強一致性和弱一致性
強一致性可以理解為在任意時刻，所有節點中的資料是一樣的。同一時間點，你在節點a中獲取到key1的值與在節點b中獲取到key1的值應該都是一樣的 弱一致性 相當於非同步 系統並不保證續程序或者執行緒的訪問都會返回最新的更新過的值。系統在資料寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾...