# 簡單用個小故事解釋 CAP

今天在跟 Team member 解釋什麼是 CAP，~~最後疏理了個小故事來黑 PM~~

C:讀到的資料一定是最新的
A:一定有方法存取數據
P:部份功能異常不導致服務完全掛掉

~~Once upon a time~~ 在服務初期，我們直接讓用戶存取一台單台 MySql server，想存啥改啥全部往這台寫，沒有分區可言，這個時候他是 C。（資料一定是 Latest「C」，且因為只有一台機器，根本沒有 P 可言，一台機器掛了就全掛，也沒有 A）

接著需求下來了，不能只有單台機器掉了就服務全掛，雞蛋不能全放一個籃子裡，所以我們一拍腦門把 mysql 變成了兩台，讓用戶隨機 Access 其中一台，一台掛了就讀另一台「P」，這樣一半的系統掛了也照樣能運作「A」。

但因為你兩台系統存的資料是不一樣的，用戶會隨機讀到其中一種，因此一致性沒了「C」，代表我們成功的把系統改進成了一個 AP 的服務。
（如果我們在兩台加上一個 last write win 策略的雙向同步，那就有了最終一致性，但依然沒有強一致性，因為同步需要時間，在同步成功之前讀到的結果是不確定的）

這時候需求又下來了，PM 說不能給用戶這麼不確定的系統阿，這個系統要管錢的，你怎麼能讓用戶的帳戶馀額有可能變來變去呢？

所以我們一拍腦門決定把同步關掉，改成用 sharding，第一台管尾號 0~4 用戶的服務，第二台管尾數 5~9 用戶的服務。

這下用戶一定可以讀到 Latest 的結果了「C」，但相對的，一旦其中一台掛掉，雖然服務依然能夠響應，但一部分的的用戶會拿不到數據，屬於壞掉機器的用戶就會失去「A」，代表我們成功的把系統改進成了一個 CP 的服務。
(一個節點掛了服務依然還在)

結果需求又下來了

不行啊，我們要公平對待用戶，不能說一部分的服務掛了，就讓一部分的用戶直接無法使用，這樣用戶一發現肯定罵我們差別待遇。

所以我們決定把服務讀取上分佈式鎖，並且每一臺都有全量數據，也不會有一個用戶的額度變動的狀況了(C)，而且任何一台都可以讀，但資料一旦分區就會導致該區塊服務不可用直到完全同步，代表我們成功的把系統改進成了一個 AC 的服務。

然而這時候剛上完 「30 天速成分布式系統」的 PM 回來了，表示我們的系統不能那麼薄弱，要有 114514 個 9 的 SLA，分布式系統不能只有單台機器掉了就服務全掛......

什么是BASE

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

Basically Available（基本可用）分布式系统在出现不可预知故障的时候，允许损失部分可用性

Soft state（软状态）软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

Eventually consistent（最终一致性）最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性# CAP 与 BASE 关系