CAP 和 BASE 理論

CAP 理論

一個分佈式系統最多隻能同時知足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這其中這兩項mysql

一致性(Consistency)

指全部節點在同一時間看到的數據徹底一致,這裏說的就是數據一致性。
其中一致性又能夠分爲sql

  • 強一致性:CAP 理論中的一致性就是指的強一致性。好比一個主從結構的 MySQL 集羣,強一致性則要求對主庫的寫必須在從庫同步完成後纔對外部可見,這樣全部用戶在同一時間點看到的數據就是一致的。
  • 弱一致性:數據更新成功後,系統不承諾當即讀到最新的值,也不承諾具體多久能讀到最新的值
  • 最終一致性:弱一致性的一種形式,數據更新成功後可能會存在短暫的不一致,可是在過一段時間後,結點間的數據最終會達到一致性。

可用性(Availability)

可用性是指分佈式服務一直處於可用狀態,即用戶發起的請求老是可以在有限時間內處理而且返回。數據庫

在衡量分佈式系統的可用性的時候,通常是經過停機時間來計算的。服務器

可用性類型 可用水平(%) 年可容忍停機時間
容錯可用性 99.9999 < 1 min
極高可用性 99.999 < 5 min
具備故障自動恢復能力的可用性 99.99 < 53 min
高可用性 99.9 < 8.8 h
商品可用性 99 < 43.8h

分區容錯性(Partition Tolerance)

分佈式系統在遇到某結點或者網絡分區故障的時候,仍然可以正常對外提供服務網絡

CAP 理論證實

假設此時有 N1 和 N2 兩臺計算機分別部署應用 A 和 B 同時 A 對應的數據庫爲 D1,B 對應的數據庫是 D2,假設若是能同時知足 CAP 特性他們應該是這樣的

  • 知足一致性:D1 和 D2 數據始終一致
  • 知足可用性:不管是請求 N1 服務器仍是請求 N2 服務器,都可以正常響應,而且D1 和 D2 數據可以達到一致性
  • 知足分區容錯性:N1 或者 N2 其中一臺服務器不可用了,也可以正常對外提供服務

假設架構

  • 外部請求 N1 和 N2 可否正常響應做爲可用性
  • N1 和 N2 之間網絡環境做爲分區容錯性
  • D1 和 D2 之間的數據是否同樣做爲一致性

因爲在單機的狀況數據庫是能夠保證其自身事務的 ACID 特性的,在分佈式環境中主要影響他們的則是網絡通訊問題這個不肯定因數,可是對於分佈式服務來講,在部分服務器網絡通訊出現異常的時候也必須可以正常響應也就是分佈式系統必需要知足分區容錯性,不知足分區容錯性的分佈式服務沒有意義。併發

因此咱們這裏只討論,在知足分區容錯性的前提下是否可以同時知足一致性和可用性這 2 種狀況異步

  1. 知足一致性,在這種狀況下,必須得保證 D1 和 D2 數據的一致性。那麼若是要再知足可用性的話,由於某一臺服務器可能不可用了,這樣 D1 和 D2 沒法數據同步了,這樣就和一致性衝突了,必須等待等到不可用的服務器恢復以後才能正常提供服務。
  2. 知足可用性,在這種狀況下,若是要去知足一致性則沒法作到了,由於某一臺機器不可用了,數據不可能達到一致性

在此就能看出咱們在知足分區容錯性的前提下,只能在一致性和可用性中二選一。分佈式

這裏的二選一中的一致性是指的是強一致性,咱們能夠退而求其次的選擇最終一致性方案。由於最終一致性方案可能會致使中間有一段時間內數據是不一致的,因此具體選用仍是要分狀況。好比涉及到金錢相關的操做,能夠只選擇分區容錯性和一致性,即出現分區故障的時候優先保證數據的一致性,讓服務暫時不可用這樣的場景在銀行等機構都有使用,咱們能夠權衡使用。高併發

CAP 權衡

CA without P

保證一致性和可用性捨棄分區容錯性。這樣的場景幾乎不存在,捨棄分區容錯性意味着捨棄分佈式系統,咱們只能想辦法去增強基礎設施建設區下降網絡分區的發生。

CP without A

保證一致性和分區容錯性而捨棄可用性。這意味着若是發生網絡分區,那麼系統會處於不可用狀態直到網絡分區的恢復。

知足這種性質的其實仍是挺多的好比 Zookeeper 它會優先保證 CP,好比金融機構某些核心的金融業務優先保證 CP 系統暫時的不可用也比資金流失好多了。

AP without C

保證可用性和分區容錯性捨棄一致性。這裏捨棄的是強一致性,某些應用能夠退而求其次的選擇最終一致性。

強一致性通常是採用 XA 協議來實現的它採用 2 PC 協議 其中可能涉及到長時間的阻塞而致使系統併發性下降吞吐量急劇降低,沒法知足高併發下的場景

因此說不少大型應用都是選擇的 AP without C 而後保證最終一致性,好比在淘寶商城購買商品發現還有庫存,可是下單支付的時候卻提示庫存不足,好比在 12306 搶票的時候看到還有票結果支付的時候卻提示餘票不足(相信你們都有過相似體驗)這樣的狀況其實無傷大雅。

BASE 理論

在 CAP 理論中咱們講了,系統沒法同時知足 CAP,可是能夠退而求其次的選擇 AP 而後保證最終一致性

eBay的架構師Dan Pritchett源於對大規模分佈式系統的實踐總結,在ACM上發表文章提出BASE理論,BASE理論是對CAP理論的延伸,核心思想是即便沒法作到強一致性(Strong Consistency,CAP的一致性就是強一致性),但應用能夠採用適合的方式達到最終一致性(Eventual Consitency)

基本可用(BASE)

基本可用是指容許損失部分可用性,保證核心可用便可。

好比在秒殺場景中,爲了應對用戶可能出現的激增狀況,要保證服務器不會所以出現錯誤,那麼達到服務器承載的上限後,服務器就只能爲後續的請求提供降級服務了,將後面一部分用戶的請求進行排隊或者是引導到降級頁面去,這就是損失部分可用性,保證核心可用的一種體現。

軟狀態(Soft State)

軟狀態是指容許系統存在中間狀態,而該中間狀態不會影響系統的總體可用性。分佈式存儲中通常至少會有三個副本,容許不一樣節點間副本同步的延時就是軟狀態的體現,mysql replication 的異步複製也是一種體現。

最終一致性(Eventual Consistency)

最終一致性是指系統中的全部數據副本通過必定時間後,最終都能達到一致性的狀態,是弱一致性的一種體現

參考:

相關文章
相關標籤/搜索