溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q
一、分布式鎖
數據庫的唯一索引
Redis 的 SETNX 指令
Redis 的 RedLock 算法
Zookeeper 的有序節點
二、分布式事務
2PC
本地消息表
三、CAP
一致性
可用性
分區容忍性
權衡
四、BASE
基本可用
軟狀態
最終一致性
五、Paxos
執行過程
約束條件
六、Raft
單個 Candidate 的競選
多個 Candidate 競選
數據同步
在單機場景下，可以使用語言的內置鎖來實現進程同步。但是在分布式場景下，需要同步的進程可能位于不同的節點上，那么就需要使用分布式鎖。
阻塞鎖通常使用互斥量來實現：
互斥量為 0 表示有其它進程在使用鎖，此時處于鎖定狀態；
互斥量為 1 表示未鎖定狀態。
1 和 0 可以用一個整型值表示，也可以用某個數據是否存在表示。
獲得鎖時向表中插入一條記錄，釋放鎖時刪除這條記錄。唯一索引可以保證該記錄只被插入一次，那么就可以用這個記錄是否存在來判斷是否存于鎖定狀態。
存在以下幾個問題：
鎖沒有失效時間，解鎖失敗的話其它進程無法再獲得該鎖。
只能是非阻塞鎖，插入失敗直接就報錯了，無法重試。
不可重入，已經獲得鎖的進程也必須重新獲取鎖。
使用 SETNX（set if not exist）指令插入一個鍵值對，如果 Key 已經存在，那么會返回 False，否則插入成功并返回 True。
SETNX 指令和數據庫的唯一索引類似，保證了只存在一個 Key 的鍵值對，那么可以用一個 Key 的鍵值對是否存在來判斷是否存于鎖定狀態。
EXPIRE 指令可以為一個鍵值對設置一個過期時間，從而避免了數據庫唯一索引實現方式中釋放鎖失敗的問題。
使用了多個 Redis 實例來實現分布式鎖，這是為了保證在發生單點故障時仍然可用。
嘗試從 N 個互相獨立 Redis 實例獲取鎖；
計算獲取鎖消耗的時間，只有當這個時間小于鎖的過期時間，并且從大多數（N / 2 + 1）實例上獲取了鎖，那么就認為鎖獲取成功了；
如果鎖獲取失敗，就到每個實例上釋放鎖。
Zookeeper 提供了一種樹形結構的命名空間，/app1/p_1 節點的父節點為 /app1。
永久節點：不會因為會話結束或者超時而消失；
臨時節點：如果會話結束或者超時就會消失；
有序節點：會在節點名的后面加一個數字后綴，并且是有序的，例如生成的有序節點為 /lock/node-0000000000，它的下一個有序節點則為 /lock/node-0000000001，以此類推。
為一個節點注冊監聽器，在節點狀態發生改變時，會給客戶端發送消息。
創建一個鎖目錄 /lock；
當一個客戶端需要獲取鎖時，在 /lock 下創建臨時的且有序的子節點；
客戶端獲取 /lock 下的子節點列表，判斷自己創建的子節點是否為當前子節點列表中序號最小的子節點，如果是則認為獲得鎖；否則監聽自己的前一個子節點，獲得子節點的變更通知后重復此步驟直至獲得鎖；
執行業務代碼，完成后，刪除對應的子節點。
如果一個已經獲得鎖的會話超時了，因為創建的是臨時節點，所以該會話對應的臨時節點會被刪除，其它會話就可以獲得鎖了。可以看到，Zookeeper 分布式鎖不會出現數據庫的唯一索引實現的分布式鎖釋放鎖失敗問題。
一個節點未獲得鎖，只需要監聽自己的前一個子節點，這是因為如果監聽所有的子節點，那么任意一個子節點狀態改變，其它所有子節點都會收到通知（羊群效應），而我們只希望它的后一個子節點收到通知。
指事務的操作位于不同的節點上，需要保證事務的 ACID 特性。
例如在下單場景下，庫存和訂單如果不在同一個節點上，就涉及分布式事務。
兩階段提交（Two-phase Commit，2PC），通過引入協調者（Coordinator）來協調參與者的行為，并最終決定這些參與者是否要真正執行事務。
協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。
如果事務在每個參與者上都執行成功，事務協調者發送通知讓參與者提交事務；否則，協調者發送通知讓參與者回滾事務。
需要注意的是，在準備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知后，才進行提交或者回滾。
所有事務參與者在等待其它參與者響應的時候都處于同步阻塞狀態，無法進行其它操作。
協調者在 2PC 中起到非常大的作用，發生故障將會造成很大影響。特別是在階段二發生故障，所有參與者會一直等待，無法完成其它操作。
在階段二，如果協調者只發送了部分 Commit 消息，此時網絡發生異常，那么只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務，使得系統數據不一致。
任意一個節點失敗就會導致整個事務失敗，沒有完善的容錯機制。
本地消息表與業務數據表處于同一個數據庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性，并且使用了消息隊列來保證最終一致性。
在分布式事務操作的一方完成寫業務數據的操作之后向本地消息表發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
之后將本地消息表中的消息轉發到消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
在分布式事務操作的另一方從消息隊列中讀取一個消息，并執行消息中的操作。
分布式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區容忍性（P：Partition Tolerance），最多只能同時滿足其中兩項。
一致性指的是多個數據副本是否能保持一致的特性，在一致性的條件下，系統在執行數據更新操作之后能夠從一致性狀態轉移到另一個一致性狀態。
對系統的一個數據更新成功之后，如果所有用戶都能夠讀取到最新的值，該系統就被認為具有強一致性。
可用性指分布式系統在面對各種異常時可以提供正常服務的能力，可以用系統可用時間占總時間的比值來衡量，4 個 9 的可用性表示系統 99.99% 的時間是可用的。
在可用性條件下，要求系統提供的服務一直處于可用的狀態，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。
網絡分區指分布式系統中的節點被劃分為多個區域，每個區域內部可以通信，但是區域之間無法通信。
在分區容忍性條件下，分布式系統在遇到任何網絡分區故障的時候，仍然需要能對外提供一致性和可用性的服務，除非是整個網絡環境都發生了故障。
在分布式系統中，分區容忍性必不可少，因為需要總是假設網絡是不可靠的。因此，CAP 理論實際上是要在可用性和一致性之間做權衡。
可用性和一致性往往是沖突的，很難使它們同時滿足。在多個節點之間進行數據同步時，
為了保證一致性（CP），不能訪問未同步完成的節點，也就失去了部分可用性；
為了保證可用性（AP），允許讀取所有節點的數據，但是數據可能不一致。
BASE 是基本可用（Basically Available）、軟狀態（Soft State）和最終一致性（Eventually Consistent）三個短語的縮寫。
BASE 理論是對 CAP 中一致性和可用性權衡的結果，它的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。
指分布式系統在出現故障的時候，保證核心可用，允許損失部分可用性。
例如，電商在做促銷時，為了保證購物系統的穩定性，部分消費者可能會被引導到一個降級的頁面。
指允許系統中的數據存在中間狀態，并認為該中間狀態不會影響系統整體可用性，即允許系統不同節點的數據副本之間進行同步的過程存在時延。
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步后，最終能達到一致的狀態。
ACID 要求強一致性，通常運用在傳統的數據庫系統上。而 BASE 要求最終一致性，通過犧牲強一致性來達到可用性，通常運用在大型分布式系統中。
在實際的分布式場景中，不同業務單元和組件對一致性的要求是不同的，因此 ACID 和 BASE 往往會結合在一起使用。
用于達成共識性問題，即對多個節點產生的值，該算法能保證只選出唯一一個值。
主要有三類節點：
提議者（Proposer）：提議一個值；
接受者（Acceptor）：對每個提議進行投票；
告知者（Learner）：被告知投票的結果，不參與投票過程。
規定一個提議包含兩個字段：[n, v]，其中 n 為序號（具有唯一性），v 為提議值。
下圖演示了兩個 Proposer 和三個 Acceptor 的系統中運行該算法的初始過程，每個 Proposer 都會向所有 Acceptor 發送 Prepare 請求。
當 Acceptor 接收到一個 Prepare 請求，包含的提議為 [n1, v1]，并且之前還未接收過 Prepare 請求，那么發送一個 Prepare 響應，設置當前接收到的提議為 [n1, v1]，并且保證以后不會再接受序號小于 n1 的提議。
如下圖，Acceptor X 在收到 [n=2, v=8] 的 Prepare 請求時，由于之前沒有接收過提議，因此就發送一個 [no previous] 的 Prepare 響應，設置當前接收到的提議為 [n=2, v=8]，并且保證以后不會再接受序號小于 2 的提議。其它的 Acceptor 類似。
如果 Acceptor 接收到一個 Prepare 請求，包含的提議為 [n2, v2]，并且之前已經接收過提議 [n1, v1]。如果 n1 > n2，那么就丟棄該提議請求；否則，發送 Prepare 響應，該 Prepare 響應包含之前已經接收過的提議 [n1, v1]，設置當前接收到的提議為 [n2, v2]，并且保證以后不會再接受序號小于 n2 的提議。
如下圖，Acceptor Z 收到 Proposer A 發來的 [n=2, v=8] 的 Prepare 請求，由于之前已經接收過 [n=4, v=5] 的提議，并且 n > 2，因此就拋棄該提議請求；Acceptor X 收到 Proposer B 發來的 [n=4, v=5] 的 Prepare 請求，因為之前接收到的提議為 [n=2, v=8]，并且 2 <= 4，因此就發送 [n=2, v=8] 的 Prepare 響應，設置當前接收到的提議為 [n=4, v=5]，并且保證以后不會再接受序號小于 4 的提議。Acceptor Y 類似。
當一個 Proposer 接收到超過一半 Acceptor 的 Prepare 響應時，就可以發送 Accept 請求。
Proposer A 接收到兩個 Prepare 響應之后，就發送 [n=2, v=8] Accept 請求。該 Accept 請求會被所有 Acceptor 丟棄，因為此時所有 Acceptor 都保證不接受序號小于 4 的提議。
Proposer B 過后也收到了兩個 Prepare 響應，因此也開始發送 Accept 請求。需要注意的是，Accept 請求的 v 需要取它收到的最大提議編號對應的 v 值，也就是 8。因此它發送 [n=4, v=8] 的 Accept 請求。
Acceptor 接收到 Accept 請求時，如果序號大于等于該 Acceptor 承諾的最小序號，那么就發送 Learn 提議給所有的 Learner。當 Learner 發現有大多數的 Acceptor 接收了某個提議，那么該提議的提議值就被 Paxos 選擇出來。
指只有一個提議值會生效。
因為 Paxos 協議要求每個生效的提議被多數 Acceptor 接收，并且 Acceptor 不會接受兩個不同的提議，因此可以保證正確性。
指最后總會有一個提議生效。
Paxos 協議能夠讓 Proposer 發送的提議朝著能被大多數 Acceptor 接受的那個提議靠攏，因此能夠保證可終止性。
Raft 也是分布式一致性協議，主要是用來競選主節點。
有三種節點：Follower、Candidate 和 Leader。Leader 會周期性的發送心跳包給 Follower。每個 Follower 都設置了一個隨機的競選超時時間，一般為 150ms~300ms，如果在這個時間內沒有收到 Leader 的心跳包，就會變成 Candidate，進入競選階段。
下圖展示一個分布式系統的最初階段，此時只有 Follower 沒有 Leader。Node A 等待一個隨機的競選超時時間之后，沒收到 Leader 發來的心跳包，因此進入競選階段。
此時 Node A 發送投票請求給其它所有節點。
其它節點會對請求進行回復，如果超過一半的節點回復了，那么該 Candidate 就會變成 Leader。
之后 Leader 會周期性地發送心跳包給 Follower，Follower 接收到心跳包，會重新開始計時。
如果有多個 Follower 成為 Candidate，并且所獲得票數相同，那么就需要重新開始投票。例如下圖中 Node B 和 Node D 都獲得兩票，需要重新開始投票。
由于每個節點設置的隨機競選超時時間不同，因此下一次再次出現多個 Candidate 并獲得同樣票數的概率很低。
來自客戶端的修改都會被傳入 Leader。注意該修改還未被提交，只是寫入日志中。
Leader 會把修改復制到所有 Follower。
Leader 會等待大多數的 Follower 也進行了修改，然后才將修改提交。
此時 Leader 會通知的所有 Follower 讓它們也提交修改，此時所有節點的值達成一致。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
