1.4 數據一致性

在大數據系統中，為了獲得系統可用性，需要為同一數據分片存儲多份副本，業界的常規做法是一個數據分片同時保存三個副本。將數據復制成多份除了能增加存儲系統的可用性，同時還能增加讀操作的并發性，但引發了數據一致性問題，即同一數據分片存在多個副本。在并發的寫請求下，如何保持數據一致性尤為重要，即在存儲系統外部的使用者看來，即使存在多個副本數據，它與單份數據也應該是一樣的。

CAP、BASE、ACID等基本原則是分布式環境下數據一致性方案設計重要的指導原則。

1.4.1 CAP原則

CAP是對Consistency/Availability/Partition Tolerance的一種簡稱，CAP原則對分布式系統中的三個特性進行了如下歸納。

●一致性（Consistency）：在分布式系統中的所有數據備份，在同一時刻是否具有同樣的值（等同于所有節點訪問同一份最新的數據副本）。

●可用性（Availability）：在集群中，一部分節點出現故障后，集群整體是否還能響應客戶端的讀寫請求（對數據更新具備高可用性）。

●分區容錯性（Partition Tolerance）：從實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

CAP原則是指對于一個大規模分布式數據系統來說，CAP三個特性不可兼得，同一個系統至多只能實現其中的兩個，而必須放寬第三個要素來保證其他兩個要素被滿足。即要么AP，要么CP，抑或AC，但是不存在CAP，如圖1-1所示。

我們可以認為，在網絡環境下，運行環境出現網絡分區是不可避免的，所以系統必須具備分區容忍性特性，于是，一般在此種場景下，設計大規模分布式系統時，架構師往往在AP和CP中進行權衡和選擇，有所強調、有所放棄。

在一個分布式系統中，如果數據無副本，那么系統首先就滿足強一致性條件，單一副本數據，不可能發生數據不一致的情況。此時，系統具備C，如果我們容忍分區容錯性P，意味著系統可能發生網絡分區狀況，如有宕機現象出現時，就必然導致某些數據不可訪問，此時，可用性A是不能被滿足的，即在此情形下獲得了CP特性，但CAP不可同時滿足。

如果系統中數據有副本，假設一份數據有分別存儲在不同機器上的兩個副本，最初數據是保持一致的，某一時刻，機器1上對這個數據進行了更新操作，這個更新操作隨后會同步到機器2上，使兩個副本保持一致性。但網絡分區是不可忽視的，可以設想，在數據復制同步未完成的情況下，發生了網絡分區，導致兩臺機器無法通信，這時，我們就不得不在C或A之間做權衡和選擇。如果希望系統可用性優先（選擇A），那么對于讀取機器2上的數據查詢請求返回的并非是最新的數據，此種選擇就放棄一致性（C），產生數據不一致情況。如果選擇一致性優先（選擇C），那么，在兩臺機器恢復通信并將數據同步到一致狀態前，對于機器2就要拒絕對數據的讀請求，此時，可用性無法保證（放棄A）。所以不論選擇哪一個，必然以犧牲另外一個因素作為代價，也就是說，要么AP，要么CP，但不會有CAP。

對于分布式系統來說，分區容錯性是天然具備的，所以在設計具體分布式架構技術方案時，只能對一致性和可用性兩個特性做出取舍，要么選擇強一致性，減弱服務可用性，要么選擇高可用性而容忍弱一致性。

我們可以回顧一下傳統關系數據庫的ACID特性，在CAP三要素中，傳統關系數據庫選擇CA兩個特性，即強一致性、高可用性，與分區容錯性這個天然要素不可調和，這是造成其在分布式環境下可擴展性差的根本原因。而NoSQL系統則更關注AP因素，即高可用性和分區容錯性，也意味著兼顧高可用性和高可擴展性，而犧牲強一致性。對于絕大多數互聯網應用來說，高可用性直接涉及用戶體驗，而對數據一致性要求并不高，NoSQL系統這類以弱一致性作為代價的系統，正是適應了這一現實需求。

網絡分區（P）雖然是個天然屬性，但在現代的實際系統中，依然是個小概率事件。以此為出發點，我們并不應該為了容忍這種小概率事件而在設計之初就選擇放棄A或者放棄C，在大多數沒有出現網絡分區的狀況下，還是可以盡可能兼顧AC兩者，即有條件地兼顧CAP三要素。

另一個需要說明的是，即使必須在AC之間做出取舍，也不應該是粗粒度地在整個系統級別進行取舍，即整個系統要么取A舍C，要么取C舍A，而是應該考慮系統中存在不同的子系統，甚至應該在不同的系統運行時或者在不同的數據間進行靈活的差異化的細粒度取舍，即可能對不同子系統采取不同的取舍策略，在不同的系統運行時，對不同數據采取不同的取舍策略。因此，CAP三者并非是絕對的兩要素有或沒有，可以看作是在一定程度上的有或沒有，考慮的是在多大程度上進行取舍。

由此可以看出，CAP的修改策略是可取的。在絕大多數系統未產生網絡分區的情形下，應該盡可能保證AC兩者兼得，也即大多數情況下，考慮CAP三者兼得，當發生網絡分區時，系統應該能夠識別這種狀況并對其進行正確處理，在網絡分區場景下進入明確的分區模式，此時，可能會限制某些系統操作，最后，在網絡分區解決后，能夠進行善后處理，即恢復數據的一致性，或者彌補分區模式中產生的錯誤。

1.4.2 CAP與ACID

談到CAP與ACID之間存在的關系，首先因為CAP和ACID兩者都包含了A和C，但是其具體含義有所不同；其次，如果CAP中選擇A的話，在一定程度上，會影響ACID中的部分要求。

CAP與ACID兩者中盡管都包含一致性，但是，兩者的含義不同，ACID中的C指的是對操作的一致性約束，而CAP中的C指的是數據的強一致性（多副本對外表現類似于單副本），所以，可以將CAP中的C看作一致性約束的一種，即CAP中的C是ACID中的C所涵蓋語義的子集。在出現網絡分區的情形下，ACID中的C所要求的一致性約束是無法保證的，所以，在網絡分區解決后，需要通過一定手段來恢復ACID中要求的一致性。

當出現網絡分區時，ACID中的事務獨立只能在多個分區中的某個分區執行，因為事務的序列化要求通信，而當網絡分區時，明顯無法做到這點，所以只能在某個分區執行。如果多個分區都可以各自進行ACID中的數據持久化（D）操作，當網絡分區解決后，如果每個分區都提供持久化記錄，則系統可以根據這些記錄發現違反ACID一致性約束的內容，并給予修正。

1.4.3 BASE原則

關系數據庫系統采納ACID原則，獲得高可靠性和強一致性。而大多數分布式環境下的云存儲系統和NoSQL系統則采納BASE原則。BASE原則具體是指如下幾項。

●基本可用（Basically Available）：在絕大多數時間內，系統處于可用狀態，允許偶爾的失效，所以稱為基本可用。

●軟狀態或者柔性狀態（Soft State）：是指數據狀態不要求在任意時刻都完全保持同步，可以理解為系統處于有狀態（State）和無狀態（Stateless）之間的中間狀態。

●最終一致性（Eventual Consistency）：與強一致性相比，最終一致性是一種弱一致性，盡管軟狀態不要求任意時刻數據保持一致同步，但是，在給定時間窗口內，最終會達到一致的狀態。

BASE原則與ACID原則有很大的差異。BASE通過犧牲強一致性來獲得高可用性。盡管現在大多數的NoSQL系統采納了BASE原則，但是有一點值得注意：NoSQL系統與云存儲系統的發展過程正在向逐步提供局部ACID特性發展，即從全局而言，符合BASE原則，但局部上支持ACID原則，這樣，就可以吸取兩者各自的好處，在兩者之間建立平衡。

ACID強調數據的一致性，這是傳統數據庫設計的思路。而BASE更強調可用性，弱化數據強一致性的概念，這是互聯網時代對于大規模分布式數據系統的一種需求，尤其是其中的軟狀態和最終一致性。可以說，ACID和BASE原則是在明確提出CAP理論之前關于如何對待可用性和強一致性的兩種完全不同的設計思路。