訊息傳送一致性
微服務架構下，需要通過網路進行通訊，就自然引入了資料傳輸的不確定性，也就是cap原理中的p-分割槽容錯，而這裡的訊息傳送一致性是可靠訊息的保證。
生成訊息的業務動作與訊息傳送的一致（e.g： 如果業務操作成功，那麼由這個業務操作所產生的訊息一定會成功投遞出去，否則就丟失訊息）如上圖，保證訊息傳送一致性的一般流程如下：
訊息的ack確認流程中，任何乙個環節都可能會出問題！
對未ack的訊息，採用按規則重新投遞的方式進行處理（很多mq都提供at least once的投遞，持久化和重試機制），一般還會設定重發的次數， 超過次數的訊息會進入dead letter queue，等待人工干預或者延後定時處理。
業務介面的冪等性
訊息的重**送會導致業務介面出現重複呼叫的問題，主要原因就是訊息沒有及時收到ack確認導致的， 那如何實現冪等性設計呢？
在實際的業務場景中， 業務介面的冪等性設計，常結合查詢操作一起使用，
比如根據唯一標識查詢訊息是否被處理過， 或者根據消費日誌表，來維護訊息消費的記錄。
保證最終一致性的模式
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
CAP原理與最終一致性 強一致性 透析
在足球比賽裡，乙個球員在一場比賽中進三個球，稱之為帽子戲法 hat trick 在分布式資料系統中，也有乙個帽子原理 cap theorem 不過此帽子非彼帽子。cap原理中，有三個要素 cap原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取捨。而對...
Redis一致性方案
儘管到目前為止，我在專案中很少遇到快取不一致問題，僅有一次是因為 原因。就是那次讓我考慮快取不一致的解決方案，網上有很方案，例如加鎖，訊息佇列，或延遲刪除,還有監控binlog日誌，以及用lua實現樂觀鎖，但我以為這些方案都不是太理想，要麼增加了系統的複雜度，要麼不能做到實時一致性。一天我漫步在乙個...