[讀書筆記][從Paxos到Zookeeper分佈式一致性原理與實踐] 1. 分佈式系統原理和理論

1. 分佈式原理

分佈式系統是硬件和軟件分佈在不一樣網絡計算機上，彼此間經過消息傳遞進行通訊和協調的系統。

1.1 分佈式環境存在的問題

1. 通訊異常：分佈式環境存在消息丟失和消息延遲的狀況。
2. 網絡分區：在組成分佈式系統的全部節點中只有部分節點能進行正常通訊，另外一些則不能，造成網絡分區孤島，也稱爲腦裂。
3. 三態：分佈式環境請求有3種狀態，成功、失敗、超時。
4. 節點故障：分佈式環境中每一個節點都有可能出現故障。

1.2 分佈式系統特性

1. 分佈性：服務分佈在網絡的不一樣的機器上，可能會變更。
2. 副本：

• 數據副本：多節點持久化同一份數據，當某個節點宕機或存儲的數據丟失，可從副本讀取到數據，解決分佈式系統數據丟失的問題。
• 服務副本：多節點提供一樣的服務，每一個節點都能接收外部的請求並進行相應的處理。

1. 併發性：併發狀況較單點系統更爲複雜，對於共享資源的訪問須要準確和高效地協調。
2. 故障：分佈式系統中每一個節點都有可能發生故障，設計時應該充分考慮可能發生的故障和備案。

1.3 CAP和BASE理論

1.3.1 分佈式系統的幾個基本要求

• 一致性：在分佈式環境中，多個數據副本之間是否可以保持一致的特性。若是對一個數據項更新後，全部用戶在集羣其餘節點都能讀到更新後的值，那麼認爲系統具有強一致性（嚴格一致性）。
• 可用性：對於用戶的每個請求，系統能夠在有限的時間內返回結果。有限的時間隨系統類型不一樣而不一樣，是知足用戶預期的時間。返回結果是指系統應該返回正確的響應，而不是用戶沒法理解的結果，好比OutOfMemory。
• 分區容錯性：分佈式系統在遇到任何網絡分區故障時，仍須要保證對外提供一致性和可用性的服務，除非是整個網絡發生故障。

1.3.2 CAP理論

CAP理論：一個系統不可能同時知足一致性（C：Consistency）、可用性（A：Avaliability）和分區容錯性（P：Partition Tolerance）這三個基本需求，最多隻能知足其中的兩項。

那麼爲何會這樣呢？如下2個地方講的都挺好的：

1. https://www.zhihu.com/question/54105974
2. http://www.javashuo.com/article/p-tedpjipc-gy.html

經過以上2個地方的講解，歸納下本身的理解：
分區容錯性是分佈式系統的基礎，放棄則表示失去了系統的擴展性，違背了分佈式系統設計的初衷。因此一般提到CAP的取捨，是在CA之間的取捨。

• 保證分區容錯性：須要用到上文中提到的數據副本，即同一份數據分佈到不一樣的節點上，在網絡發生故障時，仍須要保證對外提供一致性和可用性的服務，除非是整個網絡發生故障。
• 保證一致性：此時爲知足分區容錯性的需求，設置了多個數據副本（副本越多，分區容錯性越強），分佈式系統須要承擔數據同步的工做。若是要保證強一致性，那麼部分節點須要犧牲可用性，等待數據同步完成後再提供服務。極端狀況下，當網絡出現故障造成網絡孤島的時候，孤島內的節點爲保證強一致性，須要完全中止服務，等待網絡恢復，同步最新的數據保證強一致性。
• 保證可用性：一樣是多個數據副本的場景，保證強可用性的一個方法便是犧牲一致性，在數據同步的同時提供服務，此時可能各個節點對同一個數據返回的值不一樣（還未完成數據同步），出現數據不一致的狀況。

這樣看來，無論單純地犧牲一致性，仍是可用性，都是不太可取的，因此會有BASE理論。

1.3.3 BASE理論

BASE理論：基本可用、軟狀態、最終一致性

• 基本可用：分佈式系統在遇到問題時，容許損失部分可用性。響應時間上的延長、功能降級。
• 軟狀態：和強一致性相比，軟狀態容許系統中的數據存在中間狀態，容許系統在不一樣節點的數據副本之間進行數據同步的延遲。
• 最終一致性：系統中的全部數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。

這樣看來，仍是能夠在一致性和可用性之間作必定的權衡，來達到一個相對滿意的狀態。