集群：相同的應用部署在多台服務器。

分布式：不同的應用部署在多台服務器。

1.數據一緻性

在分布式環境中，為了提高系統整體性能，數據以多副本冗餘機制存儲，副本之間通過數據複制進行同步。

數據副本與數據複制必然引入新的問題：如何處理副本數據的一緻性？

總的來說，無法找到一種能夠滿足所有分布式環境的一緻性解決方案，很多時候要在系統性能與數據一緻性之間權衡。

由此，分布式一緻性常見以下三種一緻性：

1.1.強一緻性

強一緻性：數據寫以後，任意時刻，所有數據副本中的數據都是一緻的。

強一緻性，也可以稱為：原子一緻性、線性一緻性。

強一緻性，是非分布式環境中主要被采用的一緻性原則。

在非分布式環境中，數據可以集中存儲，例如整個系統就一個數據庫，這種情況下容易保證數據的強一緻性。

在分布式環境中，數據存在多個副本，分布在不同的服務器上，數據副本之間的同步會經過網絡通訊，這種情況下，很難保證強一緻性。

1.2.順序一緻性

順序一緻性：任何一次讀都能讀取到數據的最近一次寫的數據，系統的所有進程的順序一緻，而且是合理的。

順序一緻性，其實本人接觸也不多，而且實際中暫時未涉及，這裡就不再贅述。

1.2.弱一緻性

弱一緻性：數據寫以後，不保證所有的數據副本何時能夠達到一緻，但是會盡可能的保證到某個時刻達到一緻。

1.3.最終一緻性

最終一緻性：數據寫以後，經過一段時間，所有數據副本中的數據最終是一緻的。

一段時間的長短是由業務場景決定的。

最終一緻性是弱一緻性的特例，是分布式環境中廣泛被采用的一緻性原則。

2.1.概念

CAP：一個分布式系統不可能同時滿足一緻性(Consistentcy)、可用性(Availability)和分區容錯性(Partition tolerance)，最多隻能滿足其中的兩項。

下面對C、A、P進行描述：

• Consistency(一緻性)：所有數據副本的數據都是一緻的。
• Availability(可用性)：所有請求都能獲取正确的響應。
• Partition Tolerance(分區容錯性)：即使發生了網絡分區，服務也能對外提供滿足一緻性和可用性的服務。

網絡分區：分布式系統由網絡連通的多個節點構成，有時由于一些特殊原因（網絡波動、異常）導緻部分節點之間出現網絡不連通的情況。這種情況下，就會形成多個孤立的子網絡或孤立節點，這些子網絡和孤立節點稱之為網絡分區。

其實在分布式系統中，首先需要保證的就是分區容錯性，否則分布式的意義就不存在了。

所以，一般情況下，我們需要權衡的是一緻性和可用性之間的平衡。

2.2.舉例驗證

下面以外賣下單為例，通過下圖進行簡單驗證：

正常情況下

用戶外賣下單，數據庫A插入外賣記錄。

數據庫A的外賣記錄通過網絡同步給數據庫B，數據庫B中存有外賣記錄。

用戶查看評論情況，評論服務獲取數據庫B的數據，顯示：外賣評論詳情。

網絡分區情況：第二步數據庫A的外賣記錄通過網絡同步給數據庫B時失敗。

此時，是否能夠同時保證Consistency和Availability呢？答案是否定的。

先保證一緻性的情況

用戶外賣下單，數據庫A插入外賣記錄。

數據庫A的外賣記錄通過網絡同步給數據庫B時失敗。

因為要保證一緻性，所以需要用戶一直等待，直至網絡恢複正常，數據庫A将最新數據同步給數據庫B。

這種情況下，相當于犧牲了可用性。

先保證可用性的情況

用戶外賣下單，數據庫A插入外賣記錄。

數據庫A的外賣記錄通過網絡同步給數據庫B時失敗。

因為要保證可用性，所以直接查詢數據庫B的舊數據，返回給用戶：無此外賣訂單。

這種情況下，相當于犧牲了一緻性。

通過上述簡單舉例，驗證了在分布式環境下，保證分區可用性的前提下，無法同時保證一緻性和可用性。

同時，也可以看出上面兩種處理方式都不太理想，那麼更加理想的處理方式是什麼呢？

3.1.概念

BASE：基本可用(Basic Availability)、軟狀态(Soft State)和最終一緻性(Eventually Consistency)。

BASE理論是在CAP定理上，依據行業實踐經驗，逐漸演化出來的一種分布式方案。

下面對BA、S、E進行描述：

基本可用：分布式系統故障時，允許損失部分可用性，提供基本可用的服務。

允許在響應時間上的可用性損失：正常情況下，外賣下單需要0.5s；異常情況下，外賣下單需要3s。

允許在功能上的可用性損失：正常情況下，訂單、評價服務都正常；異常情況下，隻保證訂單服務正常。

• 軟狀态：分布式系統中，允許存在的一種中間狀态，也叫弱狀态或柔性狀态。
• 舉例：在下單支付時，讓頁面顯示支付中，直到支付數據同步完成。
• 最終一緻性：在出現軟狀态的情況下，經過一段時間後，各項數據最終到底一緻。
• 舉例：在支付中這個軟狀态時，數據并未一緻，軟狀态結束後，最終支付數據達到一緻。

3.2舉例說明

還是以章節2.2的外賣下單示例圖為例，對BASE理論進行說明：

采取軟狀态和最終一緻性的示例

用戶外賣下單，數據庫A插入外賣記錄。

數據庫A的外賣記錄通過網絡同步給數據庫B時失敗。

此時采取最終一緻性方案，并設置軟狀态下單中。

前端頁面展示給用戶下單中，然後直到網絡恢複正常，數據庫A将最新數據同步給數據庫B，數據最終達到一緻。

用戶查看評論情況，評論服務獲取數據庫B的數據，顯示：外賣評論詳情。

采取基本可用的實例

用戶外賣下單，數據庫A插入外賣記錄。

數據庫A的外賣記錄通過網絡同步給數據庫B時失敗。

此時采取基本可用方案，有兩種方案。

方案一：損失響應時間。用戶查看評論情況時，由原來的0.5秒增長到10s，其實後端在進行數據同步。

方案二：損失功能。評論服務不是關鍵服務，可以直接降級，展示給用戶一個降級頁面。

在傳統數據庫中，事務是一項非常重要的特性，其理論基于ACID。

在分布式環境下，由于數據副本的存在，原有事務機制難以生效，此時大多會采取基于BASE理論的分布式事務。

下面簡單介紹幾類分布式事務算法，更加深入的知識請自行了解。

4.1.二階段提交算法

二階段提交，2-Phase Commit，簡稱2PC。

2PC算法有2個參與者：

• 事務參與者，即分布式事務中的多個數據節點。
• 事務協調者，整體組織和協調參與者，以保證事務最終提交或者回滾的角色。

2PC算法如下：

第一階段：準備提交

• 阻塞協調者和所有參與者。
• 協調者詢問所有參與者準備提交是否完成。
• 參與者開始事務提交前的準備工作。
• 如果參與者準備工作完成，則回複協調者準備完成，否則回複準備失敗。

第二階段：正式提交

若任意參與者回複準備失敗：

• 則協調者向所有參與者發布命令回滾。
• 所有參與者回滾事務，釋放資源，并回複回滾完成。
• 協調者收到全部回滾完成之後回滾事務。

若全部參與者都回複準備完成：

• 則協調者向所有參與者發布命令開始提交。
• 所有參與者提交事務，釋放資源，并回複提交完成。
• 協調者收到全部提交完成之後提交事務。

• 從第一階段開始阻塞所有參與者，極大影響性能。
• 在第二階段，如果協調者挂掉，則參與者進入不知所措狀态。
• 面對網絡超時，難以适從。

4.2.三階段提交算法

二階段提交，3-Phase Commit，簡稱3PC。3PC算法如下：

第一階段：可否提交

• 協調者詢問所有參與者是否可以準備提交。
• 參與者開始确認自身資源是否可以準備提交。
• 如果參與者可以準備提交，則回複協調者可以準備，否則回複無法準備。

第二階段：準備提交

• 若任意參與者回複無法準備：
• 則協調者向所有參與者發布命令終止。
• 所有參與者終止操作。
• 若全部參與者都回複可以準備：
• 與2PC第一階段類似，而且更加優化，更加複雜。

第三階段：正式提交

• 與2PC第二階段類似，而且更加優化，更加複雜。
• 3PC比2PC多了一個階段：第一階段會先詢問參與者能否準備提交，此階段不阻塞資源。
• 3PC基于一個理論：如果第一階段所有參與者返回成功，那麼成功提交的概率很大。

3PC優于2PC的幾個方面：

• 在詢問階段不阻塞資源，能夠一定程度上提高性能。
• 在第三階段，如果協調者挂掉，則能保證事務最終提交。
• 3PC同樣也存在一個問題：面對網絡超時，難以适從。

Paxos 算法解決的問題是在一個可能發生上述異常的分布式系統中如何就某個值達成一緻，保證不論發生以上任何異常，都不會破壞決議的一緻性。

一個典型的場景是，在一個分布式數據庫系統中，如果各節點的初始狀态一緻，每個節點都執行相同的操作序列，那麼他們最後能得到一個一緻的狀态。

為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一緻性算法」以保證每個節點看到的指令一緻。

Paxos算法基本上來說是個民主選舉的算法——大多數的決定會成個整個集群的統一決定。

任何一個點都可以提出要修改某個數據的提案，是否通過這個提案取決于這個集群中是否有超過半數的結點同意（所以Paxos算法需要集群中的結點是單數）。

其實，2PC/3PC都是分布式一緻性算法的殘次版本，Google Chubby的作者Mike Burrows說過這個世界上隻有一種一緻性算法，那就是Paxos，其它的算法都是殘次品。

Paxos算法保證在任何階段被打斷，都能保證最終的正确性。

由于本人水平有限，并未深入學習Paxos算法，所以隻是給出了基本介紹，有需要的同學請自行了解。

在單機應用中，當多個線程訪問共享資源時，我們通常通過synchronized關鍵字、Lock鎖、線程安全對象等措施保證資源的安全使用。

在分布式環境下，上述措施不再能滿足需求，這事，我們需要一種應用于分布式換件的加鎖機制，即：分布式鎖。

分布式鎖的實現方式有多重，如：數據庫、Redis、ZooKeeper等等。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!