一個分佈式系統最多隻能同時知足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這其中這兩項mysql
指全部節點在同一時間看到的數據徹底一致,這裏說的就是數據一致性。
其中一致性又能夠分爲sql
可用性是指分佈式服務一直處於可用狀態,即用戶發起的請求老是可以在有限時間內處理而且返回。數據庫
在衡量分佈式系統的可用性的時候,通常是經過停機時間來計算的。服務器
可用性類型 | 可用水平(%) | 年可容忍停機時間 |
---|---|---|
容錯可用性 | 99.9999 | < 1 min |
極高可用性 | 99.999 | < 5 min |
具備故障自動恢復能力的可用性 | 99.99 | < 53 min |
高可用性 | 99.9 | < 8.8 h |
商品可用性 | 99 | < 43.8h |
分佈式系統在遇到某結點或者網絡分區故障的時候,仍然可以正常對外提供服務網絡
假設架構
因爲在單機的狀況數據庫是能夠保證其自身事務的 ACID 特性的,在分佈式環境中主要影響他們的則是網絡通訊問題這個不肯定因數,可是對於分佈式服務來講,在部分服務器網絡通訊出現異常的時候也必須可以正常響應也就是分佈式系統必需要知足分區容錯性,不知足分區容錯性的分佈式服務沒有意義。併發
因此咱們這裏只討論,在知足分區容錯性的前提下是否可以同時知足一致性和可用性這 2 種狀況異步
在此就能看出咱們在知足分區容錯性的前提下,只能在一致性和可用性中二選一。分佈式
這裏的二選一中的一致性是指的是強一致性,咱們能夠退而求其次的選擇最終一致性方案。由於最終一致性方案可能會致使中間有一段時間內數據是不一致的,因此具體選用仍是要分狀況。好比涉及到金錢相關的操做,能夠只選擇分區容錯性和一致性,即出現分區故障的時候優先保證數據的一致性,讓服務暫時不可用這樣的場景在銀行等機構都有使用,咱們能夠權衡使用。高併發
保證一致性和可用性捨棄分區容錯性。這樣的場景幾乎不存在,捨棄分區容錯性意味着捨棄分佈式系統,咱們只能想辦法去增強基礎設施建設區下降網絡分區的發生。
保證一致性和分區容錯性而捨棄可用性。這意味着若是發生網絡分區,那麼系統會處於不可用狀態直到網絡分區的恢復。
知足這種性質的其實仍是挺多的好比 Zookeeper 它會優先保證 CP,好比金融機構某些核心的金融業務優先保證 CP 系統暫時的不可用也比資金流失好多了。
保證可用性和分區容錯性捨棄一致性。這裏捨棄的是強一致性,某些應用能夠退而求其次的選擇最終一致性。
強一致性通常是採用 XA 協議來實現的它採用 2 PC 協議 其中可能涉及到長時間的阻塞而致使系統併發性下降吞吐量急劇降低,沒法知足高併發下的場景
因此說不少大型應用都是選擇的 AP without C 而後保證最終一致性,好比在淘寶商城購買商品發現還有庫存,可是下單支付的時候卻提示庫存不足,好比在 12306 搶票的時候看到還有票結果支付的時候卻提示餘票不足(相信你們都有過相似體驗)這樣的狀況其實無傷大雅。
在 CAP 理論中咱們講了,系統沒法同時知足 CAP,可是能夠退而求其次的選擇 AP 而後保證最終一致性
eBay的架構師Dan Pritchett源於對大規模分佈式系統的實踐總結,在ACM上發表文章提出BASE理論,BASE理論是對CAP理論的延伸,核心思想是即便沒法作到強一致性(Strong Consistency,CAP的一致性就是強一致性),但應用能夠採用適合的方式達到最終一致性(Eventual Consitency)
基本可用是指容許損失部分可用性,保證核心可用便可。
好比在秒殺場景中,爲了應對用戶可能出現的激增狀況,要保證服務器不會所以出現錯誤,那麼達到服務器承載的上限後,服務器就只能爲後續的請求提供降級服務了,將後面一部分用戶的請求進行排隊或者是引導到降級頁面去,這就是損失部分可用性,保證核心可用的一種體現。
軟狀態是指容許系統存在中間狀態,而該中間狀態不會影響系統的總體可用性。分佈式存儲中通常至少會有三個副本,容許不一樣節點間副本同步的延時就是軟狀態的體現,mysql replication 的異步複製也是一種體現。
最終一致性是指系統中的全部數據副本通過必定時間後,最終都能達到一致性的狀態,是弱一致性的一種體現
參考: