淺談分散式系統的一致性協議（一）

2019 年 10 月 8 日
筆記

我們在Mysql系列文章中已經介紹過，我們常用的InnoDB存儲引擎是支援事務的。這裡所說的事務由一系列對系統中數據進行訪問與更新的操作所組成的一個程式執行邏輯單元。事務保證了這一組操作要麼都成功，要麼都失敗；並且事務提交之後，數據不會丟失。總結下來就是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability），即ACID四個特性。這種事務是針對單個資料庫的，資料庫底層只是在單個電腦內部通過一系列機制實現了ACID特性，不需要與其他外部數據源進行交互。從系統架構上劃分，這屬於集中式系統架構，這也符合早期做的傳統軟體項目的特點，沒有負載均衡，都是單機運行，而資料庫也是單台，只是做資料庫備份，在主庫宕掉時，切換到從庫即可。

進入互聯網應用爆發的今天，很多企業所面臨的的場景，已經不再是集中式架構，取而代之的是分散式架構，比較代表的就是阿里的去IOE（IBM-伺服器提供商，Oracle-資料庫軟體提供商，EMC-存儲設備提供商）運動。一方面分散式系統為企業帶來了成本的減少，另一方面也帶來了各種複雜的問題和挑戰：

分布、對等、並發：

在分散式系統架構里，各個節點沒有主從之分、所有機器都是對等的，並且所有的節點可能分布在不同的網路當中，互相之間通過網路進行交互，而且這些節點可能會在同一時間競爭一些共享的資源，這就需要我們在構建分散式系統應用時，應該準確且高效的解決這些並發問題；

時鐘問題：

分散式系統還有一個時鐘問題，在單台電腦內部，由作業系統內核或硬體提供時鐘系統，來協調電腦內部事件執行的先後問題；而分散式系統缺乏一個全局的時鐘序列控制；

故障問題：

分散式系統的所有節點，都可能會不可避免的發生各種情況的故障。分散式系統的黃金定理，任何在設計階段考慮到的異常情況，一定會在系統實際運行中發生，並且，在系統實際運行過程中還會遇到很多設計時未能考慮到的異常故障。

根據分散式系統常見的故障問題，總結如下：

1、通訊異常

網路通訊問題是分散式系統不可避免的因素，各個節點之間的通訊都會伴隨著網路不可用的風險，消息丟失和消息延遲的問題普遍存在。

2、網路分區

當網路發生異常時，分散式系統所有節點中，只有部分節點能夠正常通訊，而另一些節點發生異常，這個現場就是網路分區，也就是俗稱的「腦裂」。極端情況下，大集群將出現小集群，這將對分散式一致性問題提出非常大的挑戰。

3、三態

在分散式環境下，分散式系統的請求存在三種狀態，成功、失敗與超時，這與單機要麼成功，要麼失敗的場景很不相同。而且對於超時可能有兩種情況：一種是發送方沒有成功將消息的發送到接收方；另一種是接收方處理之後，響應給發送方時，網路超時，發送方沒有接收到響應。

4、節點故障

在分散式環境下，每一個節點都有出現宕機，假死的現象，而這也需要構建分散式系統時，需要考慮的容災問題，也就是節點故障，不會影響這個集群的服務。

了解了分散式系統的特點和常見問題之後，在構建分散式系統時，如何合理解決這些常見問題將是各個企業所面臨的挑戰。假如當我們構建庫存系統時，為了提升庫存系統的性能，需要引入分散式快取，這時我們需要保證快取與資料庫兩個數據源中的庫存數量一致，否則將出現超賣或者賣不出等數據不一致的問題。這就需要我們在更新庫存數據的時候，保證快取和資料庫同步進行更新，也就是分散式事務問題。當然解決方案可以有很多種，可以只更新快取，非同步更新資料庫，但要確保非同步數據不丟失，否則將出現不一致；也可以同時更新快取、資料庫，讓快取和資料庫一起成功或一起失敗，但需要自己實現快取的回滾。

其實，隨著分散式技術的發展，有很多理論在引導著我們前進，其中CAP理論被認為是業界公認的定理。CAP理論是：一個分散式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Available）和分區容錯性（P：partition tolerance）這三個基本需求，最多只能同時滿足兩項。所以，當系統架構師設計分散式系統時，既然無法同時滿足，就需要在CAP之間做相應的權衡，以適應各種業務場景。

隨著互聯網系統的發展，根據實踐逐漸演化出來的BASE理論，就是對CAP定理的一個權衡，即Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）：

基本可用是指分散式系統在出現不可預知故障的時候，允許損失部分可用性，但不等價於系統不可用，而是做一些可用性上的取捨。部分非重要系統功能的損失，也就是降級處理；允許響應時間在用戶可接受的範圍內，稍微變長；限制小部分用戶的訪問，絕大多數的請求不會影響，即限流。

弱狀態是指分散式系統中允許存在中間狀態，而這中間狀態不影響系統的整體邏輯，類似於非同步消息隊列處理延遲，數據同步延遲等，當數據達到最終狀態後，才進行處理。

最終一致性是指在分散式系統中，無法滿足強一致性，對數據一致性做的一個權衡，運行系統經過一段時間後，能夠達到一個一致性的狀態，也就是犧牲了一定的實時性。

正式由於這些經典理論的支撐，才使得分散式技術走向今天，根據長期的探索和實踐，又有一系列經典演算法出現，來解決分散式系統的問題。

2PC

兩階段提交（Two-Phase Commit）是用來處理分散式事務的一種演算法，用來保證分散式系統數據的一致性，也就是將分散式事務的提交分成了兩個節點來進行處理。