分散式理論與場景淺談

摘要： 基本理論 FLP/CAP/BASE/ACID FLP不可能原理 在非同步模型中，分散式系統中只要有一個程序不可用，就可能無法達成整體的共識. 在工程中的分散式系統實現中, 通過解決活鎖等問題, 來使系統在一定時間內可以達到一致性. 上圖裡CP還少一個常見...

基本理論

FLP/CAP/BASE/ACID

FLP不可能原理

在非同步模型中，分散式系統中只要有一個程序不可用，就可能無法達成整體的共識.

在工程中的分散式系統實現中, 通過解決活鎖等問題, 來使系統在一定時間內可以達到一致性.

上圖裡CP還少一個常見的: zookeeper

ACID 對應剛性事務, 追求強一致性, 以MySql等RDBMS為代表;

BASE 對應柔性事務, 犧牲強一致性來換取一定的可用性, 過種中會存在中間狀態, 但會達到最終一致性, 以Spanner等分散式系統為代表.

CAP理論

分散式系統中C、A、P三者不能同時滿足，最多隻能滿足其中兩個.

通常來說, 使用網路通訊的分散式系統，無法捨棄P性質, 會根據選擇的不同去達到AP或CP.

不過三者選二的情況很容易發生誤解,

1. 分割槽很少發生，那麼在系統不存在分割槽的情況下沒什麼理由犧牲C或A。
2. A與C的取捨可以在同一系統內反覆發生, A與C的程度都有很多的層次, 比如可用性的變化和一致性等級的變化等

所以實際使用中可根據應用場景進行適當取捨

以zookeeper為例, 它的CAP分別為:

• C : 最終一致性, 一般十幾秒內可以Sync到各個節點
• A : 資料總是可用, 超過一半的節點的資料是最新的, 但想保證讀到最新的資料需手動呼叫Sync函式
• P : 一是節點多了會導致寫資料時同步延時非常大, 二是節點多了Leader選舉非常耗時, 可引入 observer節點緩解

zookeeper 是一個CP系統, 因為在任何時刻對它的訪問請求能得到一致的資料結果, 但不保證每次服務請求的可用性(比如發生網路分割槽時), 所以其實它做服務發現並不如AP的 eureka 合適

分散式事務

實現最終一致性有三種模式

• 可靠事件模式, MQ配合本地或外部事件表
• 業務補償模式, 用於業務/技術異常時補償
• TCC模式, 應用層的2PC

分散式事務的需求, 主要是因為資料庫的水平拆分以及應用SOA化, 服務呼叫中會使用到跨庫事務.

從某種角度來說, 只有擁有複雜業務(如金融), 全球性服務(如谷歌), 和擁有大資料量(分庫)的公司才會有這種需求的場景.

常見的一致性協議

• ZAB
• Raft
• Viewstamped Replication
• Quorum
• Gossip

本質都是Paxos協議的變種

常見的類Paxos分散式事務實現

• MySQL的XA
• TCC, Try-Confirm-Cancel

分散式的實際業務場景

• 微信 PaxosStore
• 阿里 AliSQL X-Cluster/TCC等
• TiDB (multi raft group)
• 谷歌Spanner等
• AWS aurora, dynamo