CAP Theorem

• CAP 指的就是 “consistency 一致性”,”availability 可用性” “partition-tolerance分區容錯性”.

• consistency： 一致性是指寫操作後的讀操作可以讀取到最新的數據狀態，當數據分佈在多個節點上，從任意結點讀取到的數據都是最新的狀態。
  特點：

  • 由於數據同步過程，寫操作的響應存在一定的延遲
  • 為了保證數據一致性會對資源進行暫時鎖定，待數據同步完成釋放鎖資源
  • 如果請求數據同步失敗的結點則會返回錯誤信息，一定不會返回舊數據。

• availability： 可用性是指任何事務操作都可以得到響應結果，且不會出現響應超時或響應錯誤。
  特點：

  • 所有請求都有響應，且不會出現響應超時或響應錯誤。

• partition-tolerance：網絡中斷等問題發生後系統能正常工作，提供服務，保證一致性和可用性，不同分區之間數據同步時不影響分區數據的讀寫操作。一般來說，分區容錯無法避免，因此可以認為 CAP 的 P 總是成立。所以在CAP原則裏面，分區容錯性是必須要有的
  特點：

  • 分區容忍性分是布式系統具備的基本能力。

• 一致性、可用性和分區容錯性不可能同時全部滿足。最多只能滿足其中兩個。一致性和可用性是相互矛盾的，一般只能滿足其中之一。

CAP組合方式

• AP：犧牲了數據一致性，追求可用性和分區容錯性。可能導致全局數據不一致。客戶端發出請求之後，為了保證可用性，得到的響應可能是舊的數據，因為數據的同步需要時間，但在某些情況下舊數據也是可以接受的，通常實現AP都會保證最終一致性。比如訂單退款操作，用戶申請退款以後，得到信息」今日退款成功，明日賬戶到賬「，只要用戶接受在一定時間內到賬即可。AP的應用也比較廣泛，主要好處是可以保證數據傳遞的時效性，提高用戶體驗。AP是最常見的模型。

• CP ： 放棄可用性，追求一致性和分區容錯性。屬於強一致性。等待數據同步完才能正常訪問服務，保證用戶得到的數據一定是最新的，否則不返回數據。一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗。舉個例子，銀行跨行轉賬時，一次轉賬需要等待雙方銀行都完成整個事務的時候才算完成，這種應用場景常見於金融系統。應用有Redis、zookeeper等。

• CA：放棄了分區容錯性，保證了一致性和可用性。這就不屬於一個嚴格的分佈式系統了，任何一個分區服務器出故障，都可能導致整個系統的崩潰。關係型數據庫滿足CA，比如Oracle、MySQL。

• 以上所寫的」犧牲、放棄「等並不是表示完全怕拋棄某一個特性，而是表示降低對該特性的要求，提高另外對兩個特性的要求

CAP理論在數據庫領域的應用

附錄

提供一篇HP的關於分佈式的論文以供參考