5.3　分布式系統理論

5.3.1　了解CAP定理

CAP是分布式系統的基礎理論，它由三個單詞的首字母組成，分別代表一致性（Consistency）、可用性（Availability）和分區容錯性（Partition Tolerance）。下面我們對這三個特性做具體介紹。

1. 一致性

在分布式環境中，一份數據往往有多個數據副本，在強一致性的場景下，這些數據副本在同一時刻的值是相同的。也就是說，一個“讀”操作在多個數據副本下讀到的值也是相同的。

2. 可用性

可用性通常被稱作“高可用”，當集群中的某些節點出現故障不能響應請求的時候，集群中其他正常工作的節點依然能夠正常提供服務，使集群仍然處于可用狀態。

3. 分區容錯性

在分布式系統中某個節點或者網絡分區出現故障、區間通信可能失敗的情況下，要保證其他節點可以繼續對外提供服務。

正所謂魚和熊掌不可兼得，對分布式系統來說，以上三個特性中的一致性和可用性也只能二者選其一。背后的原因不難理解：保證強一致性就必然要犧牲一部分的可用性，在所有數據副本達到一致狀態之前不能對外提供服務；同理，可用性優先的系統往往采用了“最終一致性”的同步方案，這種方案允許暫時的數據不一致，但在未來的某個時間點會達到數據的最終一致，因此可用性優先的系統不能保證強一致性。

下面我們用一個ZooKeeper的例子來說明一致性和可用性之間的矛盾。ZooKeeper是一個一致性（CP）優先的系統，在任何時刻訪問ZooKeeper都可以獲取一致的數據，為了確保ZooKeeper各節點的數據強一致性，某些情況下ZooKeeper可能會丟棄一些請求，因而并不能保證可用性。而ZooKeeper的leader選舉過程也體現了一致性優先的策略，在ZooKeeper集群環境中有一個leader的角色，leader可以看作Master節點。在某些網絡異常的情況下，集群內的其他節點可能無法連接到leader節點，這時ZooKeeper會從剩余節點中重新選出一個leader。在這個過程中，為了保證數據的強一致性，在leader沒有選出之前，整個ZooKeeper集群都不能對外提供服務。

由于可用性和一致性無法被同時滿足，目前主流的注冊中心一般是在AP方案（可用性 + 分區容錯性）和CP方案（一致性 + 分區容錯性）之間二選一。

5.3.2　高并發應用在CAP中的偏向性

對高并發應用來說，其每秒承載的用戶請求訪問量是非常驚人的。以最近一次雙11大促場景為例，支付寶核心主鏈路每秒峰值交易處理量是52萬。對于這類應用，我們在可用性和一致性二者之間更偏向于可用性優先，這主要是從時間和資源的角度來考量的。

1. 時間角度

為了保證數據的強一致性，需要花費較長時間將數據副本同步完成之后才可以對外提供服務，這個時間成本在大訪問量基數下將被迅速放大，最終導致服務響應時間大幅拉長，因此無法保證系統的可用性。

2. 資源角度

以強一致性的XA事物解決方案為例，為了保證數據庫事物提交的強一致性，在每個分支事物完成之前，數據庫連接不會得到釋放，在大訪問量下數據庫連接資源會被快速消耗，進而導致服務不可用。

因此，從系統的整體可用性角度來考慮，高并發場景下我們更加傾向于優先保證系統的可用性，而對應的一致性解決方案通常采用“最終一致性”方案，即在未來的某一個時間點可以達到數據一致。