>>>

通常情況下業務都是由簡至繁，導致系統也會由單個拆分成多個獨立的服務，從而帶來分散式環境下資料一致性問題。

業務場景：比如有一個業務操作，同時呼叫服務A、B、C，需要滿足要麼同時成功，要麼同時失敗。A、B、C服務分別由不同部門開發，不同資料庫儲存，同時部署在不同遠端伺服器上。

在分散式系統中，如果不想犧牲一致性，CAP理論告訴我們最多實現其中2點，因為需要犧牲可用性，這顯然是不能接受的。下面先簡單介紹下資料一致性基礎理論。

強一致性

當更新完成之後，任何多個後續程序或者執行緒的訪問都會返回最新的更新過的值。這種是對使用者最友好的。

弱一致性

系統並不保證後續程序或執行緒的訪問都會返回最新更新過的值。系統在資料寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到。

最終一致性

弱一致性的特定形式。系統在保證沒有後續更新的情況下，系統最終返回上一次更新的值。在沒有故障發生的前提下，不一致

在實踐上，為了保障系統的可用性，大多會將強一致性需求轉化為最終一致性，並通過系統執行冪等性的保證，保證資料最終一致性。下面分享下一些解決方案。

1.規避分散式業務——業務整合

業務整合方案主要採用將介面整合到本地執行的方法。比如可以將服務A、B、C整合為一個服務D給業務，服務D再通過轉換為本地事務的方式。

優點：規避了分散式事務。缺點：把本來拆分好的業務又耦合到一起，業務職責不清晰，不利於維護。

2.訊息日誌的方式

此方案的核心是將需要分散式處理的任務通過訊息日誌的方式來非同步執行。訊息日誌可以儲存到本地文字、資料庫或訊息佇列，再通過業務規則自動或人工發起重試。人工重試更多的是應用於支付場景，通過對賬系統對事後問題的處理。

訊息日誌方案的核心是保證服務介面的冪等性。

考慮到網路通訊失敗，資料丟包等問題，如果服務介面不能保證冪等行，資料唯一性將很難得到保證。

BASE(basically available, soft state, eventually consistent)：一種ACID的替代方案。

BASE的可用性是通過支援區域性故障而不是全域性故障來實現的。如果將分割槽在5個數據庫伺服器上，BASE設計鼓勵類似的處理方式，一個使用者資料庫的故障隻影響這臺特定主機那20%的使用者。

一個最常見的場景，如果發生一筆交易，需要在交易表中增加記錄，同時還要修改使用者表的金額。這兩個表屬於不同的遠端服務，所以就涉及到分散式事務一致性問題。

一個不錯的解決方法，將主要修改操作以及更新使用者表訊息放在一個本地事務中來完成。同時為了避免重複消費使用者表訊息帶來的問題，達到多次重試的冪等性，增加一個更新記錄表track_msg來記錄已經處理過的訊息。

基於上面講的，在第一階段，通過本地的資料庫的事務保障，增加了transaction表及訊息佇列。

在第二階段，分別讀出訊息佇列，通過判斷更新記錄表track_msg來檢測相關記錄是否被執行，未被執行的記錄會修改user表資訊，然後增加一條記錄到track_msg,事務執行成功後再刪除佇列，從而達到分散式資料最終一致性。

儘量將分散式事務轉換為多個本地事務，通過訊息、重試等方式達到最終一致性。

分散式服務對衍生的配套系統要求比較多，特別是我們基於訊息、日誌的最終一致性方案，需要考慮訊息的積壓、消費情況、監控、報警等。

轉載於:https://my.oschina.net/nbspjj/blog/738285