前言

---

?相關系列

• 《分布式 & 目錄》
• 《分布式 & CAP理論 & 總結》
• 《分布式 & CAP理論 & 問題》
  ?
  ?

分布式

---

????分布式的核心是將大型業務拆解成多個子業務以使之在不同的機器上執行。分布式是用于解決單個物理機容量&性能瓶頸問題而采用的優化手段，服務之間通過遠程調用進行交流，從而協同工作以對外提供服務。
?
?

CAP理論

---

• Consistency @ （強）一致性：系統的所有節點在相同時刻可以看到相同數據，即對于在多個節點中存在的變量而言，其在同一時刻的值必然是相同的；
• Availability @ 可用性：無論響應結果如何，系統都可以“在合理的時間內”響應請求，即使節點因為各類故障（包含但不限于網絡分區）而不可用；
• Partition Tolerance @ 分區容錯性：系統能夠在發生（特指）網絡分區時繼續響應請求。

????所謂CAP理論指的是分布式系統無法在“讀/寫數據”時同時滿足“一致性/可用性/分區容錯性”三種特性，因此系統設計者必須在這三者之間做出權衡：

• CA策略 @ 一致性&可用性：犧牲分區容錯性來保證一致性&可用性。CA策略不屬于分布式系統的可用策略，因為以目前的技術能力而言網絡分區是無法避免的。因此如果放棄了分區容錯性，那么分布式系統在網絡分區時將完全不可用。但該策略在單機部署&單點集群部署（服務雖然被多個部署為集群，但相互間沒有交互）時是可用的，或者說單機部署&單點集群部署的程序默認就是CA策略，因為其內部不存在網絡交互，因此也就無需在意網絡分區的發生。所有程序&系統在服務未拆分/未集群的情況下采用的都是CA策略；
• CP策略 @ 一致性&分區容錯性：犧牲可用性來保證一致性&分區容錯性，適用于對數據一致性要求較高的分布式系統。當網絡分區發生時，如果節點A無法正常請求節點B以完成數據同步，那么其可以通過阻塞至網絡恢復的方式（并非只有這一種方式）來保證分區容錯性。這種方式同時還可保證一致性，因為其可保證數據的讀/寫一定是正確的。但與此同時該方法會犧牲可用性，因為阻塞可能會導致請求難以/無法被及時回應。在實際情況中，從節點A復制數據到節點B總是需要花費一定時間的。如果是跨地域（例如北京到廣州）的機房，耗費的時間就可能是幾十/幾百毫秒。因此CAP理論中的C在實踐中是不可能完美實現的，因為在數據復制的過程中節點A&B 的數據并不一致，但CAP理論并不在意這種延遲。ZooKeeper就是一個典型的CP系統，它采用分布式一致性算法（如Paxos/Raft等）來確保在不同節點之間就數據狀態達成強一致。此外，分布式一致性算法通常都帶有容錯特性，即只追求多數一致而非完全一致，故而大多數CP系統可用性其實也相當可觀；
• AP策略 @ 可用性&分區容錯性：犧牲一致性來保證可用性&分區容錯性，適用于對可用性較高的場景。當節點故障/網絡分區發生時，如果節點A無法正常請求節點B以完成數據同步，那么其可以通過放棄請求的方式（并非只有這一種方式）來保證分區容錯性。這種方式同時還可保證可用性，因為其確保了回應必然是及時的。但與此同時該方法會犧牲一致性，因為請求將難以/無法正確地讀/寫數據。AP策略通常依賴“最終一致性”模型進行彌補，即雖然會有一定的延遲，但數據最終還是會在一定時間內會達成一致。

????CAP理論策略的選擇不是一成不變的。在 CAP理論落地實踐時，我們需要將系統數據按照不同的應用場景和要求進行分類，從而為每類數據選擇不同的分布式策略，而不是直接限定整個系統的所有數據都使用同一策略。

????CAP理論告訴我們必須“犧牲”三特性中的一個，但這里的“犧牲”其實有一定誤導作用，因為“犧牲”讓很多人理解成徹底放棄。但實際上CAP理論的“犧牲”只是說我們無法在節點故障/網絡分區期間保證一致性/可用性，而現實情況是系統在整個生命周期的大部分時間里·都是正常的，發生節點故障/網絡分區現象的時間并不長。例如4個9 @ 99.99%可用性的系統一年運行下來不可用的時間只有50分鐘；而5個9 @ 99.999%可用性的系統一年運行下來不可用的時間更是只有5分鐘而已。在節點故障/網絡分區期間放棄一致性/可用性并不意味著永遠放棄，我們可以在節點故障/網絡分區期間進行一些操作，從而令分布式系統在故障解決后重新達到一致性&可用性的狀態。
?
?

BASE理論

---

????BASE理論是對CAP理論一致性&可用性進行權衡后的結果，其核心思想是即使無法做到Strong consistency @ 強一致性，但每個應用也該根據自身業務的特點采用適當的方式來使系統達到Eventual consistency @ 最終一致性。

????BASE是Basically Available @ 基本可用/Soft state @ 軟狀態/Eventually consistent @ 最終一致三個短語的簡寫，其各自含義具體如下：

• 基本可用：基本可用是指允許分布式系統在出現不可預知故障時候損失部分可用性。但注意！這絕不等價于系統不可用，以下兩個就是“基本可用”的典型例子：
  ????響應時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內返回給用戶相應的查詢結果，但由于出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1 ~ 2秒；
  ????功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
• 軟狀態：軟狀態也稱弱狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性。通俗的說就是允許系統在不同節點的數據副本之間進行同步的過程存在延時。
• 最終一致性：最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能夠達到一個一致的狀態。最終一致性的本質是需要系統數據最終能夠達到一致，而不需要實時保證系統數據的強一致性。

????BASE理論是對CAP理論AP策略的延伸&補充，是權衡一致性&可用性后的結果。BASE理論的誕生基礎是CAP理論的AP/CP策略本質實現的也是最終一致性：例如CP策略雖然名義上保證了強一致性，但現實中數據副本的同步是有延遲的，但CAP理論直接忽視了這些延遲，因此絕對完美的CP策略是不存在的；而AP策略雖然犧牲了一致性，但這種犧牲實際上也只限于節點故障/網絡分區期間，當故障恢復正常后數據同樣會恢復至最終一致。