分佈式事務／微服務架構下的數據一致性

********* https://www.cnblogs.com/szlbm/p/5588543.html

 

分佈式理論：

CAP定理

CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務沒法同時知足一下3個屬性：

• 一致性(Consistency) ： 客戶端知道一系列的操做都會同時發生(生效)
• 可用性(Availability) ： 每一個操做都必須以可預期的響應結束
• 分區容錯性(Partition tolerance) ： 即便出現單個組件沒法可用,操做依然能夠完成

具體地講在分佈式系統中，在任何數據庫設計中，一個Web應用至多隻能同時支持上面的兩個屬性。顯然，任何橫向擴展策略都要依賴於數據分區。所以，設計人員必須在一致性與可用性之間作出選擇。

一：2PC兩階段提交協議，該協議分爲如下兩個階段：

• 第一階段：事務協調器要求每一個涉及到事務的數據庫預提交(precommit)此操做，並反映是否能夠提交.
• 第二階段：事務協調器要求每一個數據庫提交數據。

3PC在兩階段基礎上增長超時處理。

    CanCommit，PreCommit，doCommit。

二：BASE理論

在分佈式系統中，咱們每每追求的是可用性，它的重要程序比一致性要高，那麼如何實現高可用性呢？ 前人已經給咱們提出來了另一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：

• Basically Available（基本可用）
• Soft state（軟狀態）
• Eventually consistent（最終一致性）

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：咱們沒法作到強一致，但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

 

分佈式事務 解決方案

1、兩階段提交（2PC）

2、補償事務（TCC）

TCC 其實就是採用的補償機制，其核心思想是：針對每一個操做，都要註冊一個與其對應的確認和補償（撤銷）操做。它分爲三個階段：

• Try 階段主要是對業務系統作檢測及資源預留

• Confirm 階段主要是對業務系統作確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm必定成功。

• Cancel 階段主要是在業務執行錯誤，須要回滾的狀態下執行的業務取消，預留資源釋放。

3、本地消息表（異步確保）

本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分佈式事務拆分紅本地事務進行處理

消息生產方，須要額外建一個消息表，並記錄消息發送狀態。消息表和業務數據要在一個事務裏提交，也就是說他們要在一個數據庫裏面。而後消息會通過MQ發送到消息的消費方。若是消息發送失敗，會進行重試發送。

消息消費方，須要處理這個消息，並完成本身的業務邏輯。此時若是本地事務處理成功，代表已經處理成功了，若是處理失敗，那麼就會重試執行。若是是業務上面的失敗，能夠給生產方發送一個業務補償消息，通知生產方進行回滾等操做。

生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。若是有靠譜的自動對帳補帳邏輯，這種方案仍是很是實用的。

這種方案遵循BASE理論，採用的是最終一致性，筆者認爲是這幾種方案裏面比較適合實際業務場景的，即不會出現像2PC那樣複雜的實現(當調用鏈很長的時候，2PC的可用性是很是低的)，也不會像TCC那樣可能出現確認或者回滾不了的狀況。

即：

（1）Producer端準備1張消息表，把update DB和insert message這2個操做，放在一個DB事務裏面。

（2）準備一個後臺程序，源源不斷的把消息表中的message傳送給消息中間件。失敗了，不斷重試重傳。容許消息重複，但消息不會丟，順序也不會打亂。

（3）Consumer端準備一個判重表。處理過的消息，記在判重表裏面。實現業務的冪等。

4、MQ 事務消息

第一階段Prepared消息，會拿到消息的地址。
第二階段執行本地事務。

第三階段經過第一階段拿到的地址去訪問消息，並修改狀態。

RocketMQ解決分佈式事務

http://blog.csdn.net/chunlongyu/article/details/53844393?from=timeline&isappinstalled=0

5、Sagas 事務模型

http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

 

Paxos 算法

第一階段：Prepare階段

A把申請修改的請求Prepare Request發給全部的結點A，B，C。注意，Paxos算法會有一個Sequence Number（你能夠認爲是一個提案號，這個數不斷遞增，並且是惟一的，也就是說A和B不可能有相同的提案號），這個提案號會和修改請求一同發出，任何結點在「Prepare階段」時都會拒絕其值小於當前提案號的請求。因此，結點A在向全部結點申請修改請求的時候，須要帶一個提案號，越新的提案，這個提案號就越是是最大的。

若是接收結點收到的提案號n大於其它結點發過來的提案號，這個結點會迴應Yes（本結點上最新的被批准提案號），並保證不接收其它<n的提案。這樣一來，結點上在Prepare階段里老是會對最新的提案作承諾。

優化：在上述 prepare 過程當中，若是任何一個結點發現存在一個更高編號的提案，則須要通知 提案人，提醒其中斷此次提案。

第二階段：Accept階段

若是提案者A收到了超過半數的結點返回的Yes，而後他就會向全部的結點發布Accept Request（一樣，須要帶上提案號n），若是沒有超過半數的話，那就返回失敗。

當結點們收到了Accept Request後，若是對於接收的結點來講，n是最大的了，那麼，它就會修改這個值，若是發現本身有一個更大的提案號，那麼，結點就會拒絕修改。

 

https://mp.weixin.qq.com/s?__biz=MzA4NDc2MDQ1Nw==&mid=2650238031&idx=1&sn=d7ba7844f15d587c83906aedd073748a&mpshare=1&scene=1&srcid=1024bnPerFqUMufkSC8uzmMI&key=93f66e49714b3d734c88f2c68d820c505a898bd42b9c9714296f5216e5c4d40a9681644c993864c293a59ab6b3397948a6160d2a015c134991150f71c25230a74a02d490cacb42bf6d9cb8b8b19a68b2&ascene=0&uin=Mjc5Nzc3MDE4MA%3D%3D&devicetype=iMac+MacBookPro12%2C1+OSX+OSX+10.12.2+build(16C67)&version=12020010&nettype=WIFI&fontScale=100&pass_ticket=v8qHthuF0zac388%2Bnxt6zRpmvjTkgXdRZTxPzbb1XcT29GVsDtF%2BAT1fKF5TN0wb

 

https://waylau.com/distributed-system-transaction/

 

 

https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247486826&idx=1&sn=e28b4ba3d42aadbe46f81cdf3f07c424&chksm=96c9bb0aa1be321c29dc6238e8332f9c5545c183d996c206a455615a78f53fea63faf1552e40&scene=27#wechat_redirect