分佈式系統之一致性和數據複製

文章來源：www.liangsonghua.me
做者介紹：京東資深工程師-梁鬆華，長期關注穩定性保障、敏捷開發、JAVA高級、微服務架構

一、一致性常見問題

這些問題離咱們並不遙遠,數據分散在多處會致使數據不一致，必須儘量地解決此問題，才能保證良好的用戶體驗，最終的指望是任何人、任什麼時候間、任何地點、任何接入方式、任何服務，數據都是一致的

二、一致性模式
1)、順序一致性(Sequencial Consistency）
每一個線程內部的指令都是按照程序規定的順序執行的(單個線程的視角)。線程執行的交錯順序能夠是作任意的，可是全部線程所看見的總體程序整體執行順序都是同樣的(總體程序的視角)

2)、弱一致性-因果一致性(Casual Consistency)
若是節點A在更新完某個數據後通知了節點B，那麼節點B以後對該數據的訪問和修改都是基於A更新後的值。於此同時，和節點A無因果關係的節點C的數據訪問則沒有這樣的限制

3)、弱一致性-入口一致性(Entry Consistency)
入口一致性要求每一個普通的共享數據都要與某種同步變量如鎖(lock)或屏障(barrier)相關聯

進程2在沒有獲取」y」數據的訪問鎖時，讀取的值將爲NIL(In the following figures, since Process2 does not hold the access right (= synchronous variable) to the data item 「y」, the reading result becomes NIL)

四、弱一致性-最終一致性(Eventual consistency)

5)、弱一致性-以客戶爲中心的一致性（Client-centric consistency model)
包括如下四種體現

（1)、單調讀一致性(Monotonic reading)
若是一個進程從系統中讀取出一個數據項X的某個值後，該進程對於X後續訪問都不該該返回更舊的值(If a process reads data item x, any subsequent reads on x by that process will either reply with the same value or reply with a newer value)

例子：任什麼時候候你登陸郵箱服務，它都能保證你上次訪問服務器時能夠讀取的郵件如今均可以查看

(2)、單調寫一致性(Monotonic writing)
一個系統要可以保證來自同一個進程的寫操做被順序的執行,它相似以數據爲中心的FIFO一致性，不過它強調的是在單一進程的順序約束而不是併發進程集(A write operation by one process to a data item x is completed before any subsequent write to x by the same process)

(3)、寫後讀一致性(Read Your Writes)
進程更新一個數據後，它老是能訪問到自身更新過的最新值，而不會看到舊值(The result of a write operation by a process to data item x is always observed by subsequent read operations by the same process)

例子：好比當你更新一個系統的管理密碼時，必須保證更新後的密碼不管你在任何地方登陸時都有效

（4)、讀後寫一致性(Writes Follow Reads)
同一個進程對數據項X執行的讀操做以後的寫操做，保證發生在與X讀取值相同或比之更新的值上(The result of a write operation by a process to data item x is always observed by subsequent read operations by the same process)

一致性模式描述的是嚴格一致性、因果一致性和順序一致性，保證了系統不會出現髒寫、髒讀、不可重複讀、幻讀、更新丟失的壞帳

三、解決思路-ACID

最多見的實現方式是WAL(write ahead loging)技術,它並不直接寫入到系統文件中，而是寫入到另一個稱爲WAL的文件中；若是事務失敗，WAL中的記錄會被忽略，撤銷修改；若是事務成功，它將在隨後的某個時間被寫回到系統文件中，提交修改

四、解決思路-CAP
ARTS-13-分佈式系統入門和實踐筆記
連接:www.liangsonghua.me

五、解決思路-BASE
基本可用、中間(軟)狀態、最終一致

六、常看法決方案
1)、兩階段提交-2PC

TM存在單點問題，並且會同步阻塞，產生資源鎖定，併發低的狀況

2)、補償機制-TCC

針對每一個操做，註冊一個與其對應的確認和補償(撤銷)操做，對業務侵入性大，須要設計複雜的重試、冪行、日記記錄模塊

3)、補償機制-Saga

流程：

(1)、訂單服務建立最終狀態未知的訂單記錄
(2)、訂單服務建立一個CreateOrderSaga負責協調訂單
(3)、CreateOrderSaga發送ReserveCredit指令至用戶服務
(4)、用戶服務接受到指令而後爲此訂單預扣款，同時回覆一條代表結果的信息
(5)、CreateOrderSaga接受到信息後，發送經過或拒絕指令到訂單服務
(6)、訂單服務接受到指令後修改其狀態

Saga能夠看作是一個異步的、事件驅動的補償事務，由Sage工做流引擎協調，其適用於無需馬上返回業務發起方最終狀態的場景,可是它不保證隔離性

連接：https://github.com/eventuate-...

4)、基於MQ-本地消息表

將分佈式事務拆分紅本地事務進行處理

5)、基於MQ-事務消息

6)、經典實現-Seata

一個典型的分佈式事務過程：

(1)、TM 向 TC 申請開啓一個全局事務，全局事務建立成功並生成一個全局惟一的 XID
(2)、XID 在微服務調用鏈路的上下文中傳播
(3)、RM 向 TC 註冊分支事務，將其歸入 XID 對應全局事務的管轄
(4)、TM 向 TC 發起針對 XID 的全局提交或回滾決議
(5)、TC 調度 XID 下管轄的所有分支事務完成提交或回滾請求

連接：https://github.com/seata/seata

七、數據複製
1)、服務端(Server Startup Replica)

2)、客戶端(Client Startup Replica)
緩存失效時長不宜過長

八、數據同步
須要數據多備份就意味着須要內容同步，常見的方式有

1)、 將更新通知傳輸到副本(Propagate only updates notifications)
2)、 將更新數據傳輸到副本(Transmit update data from one copy to another)
3)、 將更新操做傳輸到副本-推薦方式(Propagate update operations to other replicas)

好比mysql的主從複製過程

文章來源：www.liangsonghua.me做者介紹：京東資深工程師-梁鬆華，長期關注穩定性保障、敏捷開發、JAVA高級、微服務架構