分散式架構的資料一致性

最近在使用springboot搭建微服務架構，遇到資料一致性問題，今天就對它進行一個小結。

資料一致性是分散式系統中的一個關鍵需要解決的問題，雖然分散式系統帶來了擴充套件的彈性，但是帶來了資料不一致性的風險，尤其是在不同網路隔離，實現細節透明的業務子系統之間的資料不一致風險會成倍遞增。如今衡量一個企業的軟體架構是不是有潛力的，那必須得看架構是不是分散式的，也就是說既然分散式架構如此流行，那麼資料一致性就提到了一個更高的標準了。

說道分散式架構的資料一致性困難，我們需要充CAP原理講起。

CAP原理，它就好比分散式領域的牛頓定律。C-Consistent一致性，指前後資料不一致，userA訪問資料value1但user2訪問同樣資料卻是value2，資料就不一致了。A-Availability可用性，指使用者請求就要給出迴應。P-Partition

tolerance分割槽容錯性，指大多數分散式系統都分佈在多個子系統，區間通訊可能失敗，比如兩臺伺服器發生了網路分割槽，拿著兩臺伺服器無法通訊。這三個變數相互制約，對於系統設計的場景分別採取不同的偏重策略。

舉個例子吧，分散式系統中系統S1和S2,當S1系統發生寫操作，要保證S2的一致性，只有鎖定S2的讀操作和寫操作，鎖定期間S2是沒有可用性的。這三個變數相互制約為了提高C就會導致A、P降低或不滿足，反之亦然。

當然CAP理論已經指明系統要實現完全的一致性和可用性是不可能的，當然在CAP理論基礎上又發展了BASE模型和ACID模型等。這兩個模型各有優勢。

但是在目前比較成熟集中保證資料一致性方法，包括了強一致性、弱一致性和最終一致性。

強一致性，是當一個系統完成了資料更新操作之後，後續關聯的子系統也一併完成更新操作。這種決策使用者最友好，使用者寫了什麼，就會讀到什麼。但是根據CAP理論，這種實現犧牲了可用性。成型的技術方案比如springboot的jat+atomikos方案，他通過兩階段提交（XA協議規定）完成資料更新，客戶端必須保證按照XA協議完成編寫，並且資料庫必須是支援XA協議的資料庫，通常客戶端會將事務處理和業務處理是現在一起。這就帶了另一個不足就是帶來了事務處理和業務耦合性強增加了複雜度。

弱一致性，是系統不保證後續程序或者執行緒會訪問最新的值。成型的技術方案比如利用訊息佇列完成資料一致性，S1系統完成資料更新，將更新操作傳送到訊息佇列，S2系統從訊息佇列中獲取事件完成更新操作。這個方案在大廠被廣泛的使用，也是比較流行的一種方式。

最終一致性，它是弱一致性的特定形式。如，DNS是一個典型的最終一致性系統。

今天對分散式系統資料一致性做了小結，架構師們在設計的時候做到有的放矢，如何實現在成本利潤的最大化。