分布式協議

分布式一致性

raft 協議

分布式容錯

複製協議見：[分布式中的一致性與可用性之複製](

分布式協議主要有：

分布式事務其實是指會涉及到操作多個資料庫的事務。就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是為了保證分布式系統中的資料一致性。分布式事務處理的關鍵是必須有一種方法可以知道事務在任何地方所做的所有動作，提交或回滾事務的決定必須產生統一的結果

它保證了跨多個節點操作的原子性，也就是說要麼在所有節點上全部執行成功，要麼全部失敗。不會出現只成功某一部分的情況。

根據每個節點自己知道自己能夠是否成功的特性，我們將其分為協調者與事務參與者。通過協調者去來統一掌控所有參與者的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(rollback)訊息；否則，傳送正式提交(commit)訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)

很明顯，2pc會存在明顯的問題：

簡單來講就是保證主本與副本，以及副本之間的資料一致的問題。

如果主節點發生故障，那麼備節點就會提議自己成為主節點。因為會存在網路分割槽的緣故，所以就會有多個備節點提議自己成為主節點並且提議的時間可能也是不相同的，會存在先後順序。那麼 paxos 協議就用來保證，有多個提交協議的時候且順序不同時，如何選舉出唯一的主節點。

整個演算法的大致過程為：

第一階段：因為存在多個「提議者」，如果都提意見，那麼「接受者」接受誰的不接受誰的？太混亂了。所以，要先明確哪個「提議者」是意見領袖有權提出提議，未來，「接受者」們就主要處理這個「提議者」的提議了（這樣，也可以在提出提議時就盡量讓意見統一，謀求盡早形成多數派）。

第二階段：由上階段選出的意見領袖提出提議，「接受者」反饋意見。如果多數「接受者」接受了乙個提議，那麼提議就通過了。

有個跟選舉常識不一樣的地方，就是每個「提議者」不會執著於讓自己的提議通過，而是每個「提議者」會執著於讓提議盡快達成一致意見。

所以，為了這個目標，如果「提議者」在賄選的時候，發現「接受者」已經接受過前面意見領袖的提議了，即便「提議者」賄選成功，也會默默的把自己的提議改為前面意見領袖的提議。所以一旦賄賂成功，勝出的「提議者」再提出提議，提議內容也是前面意見領袖的提議（這樣，在謀求盡早形成多數派的路上，又前進了一步）。

這裡有點搞不懂他為啥不直接在接受者記錄各個提議，等待收集完全時，決策選出主節點吶？？

raft 演算法是近幾年很火的乙個分布式一致性演算法，旨在提供分布式一致性的前提下，提高演算法的可讀性，降低實現的難度。它提供了和paxos演算法相同的功能和效能，但是它的演算法結構和 paxos不同，使得 raft演算法更加容易理解並且更容易構建實際的系統。為了提公升可理解性，raft將一致性演算法分解成了幾個關鍵模組，例如領導人選舉、日誌複製和安全性。

raft集群伺服器的狀態有三種：

候選人(candidate)：

跟隨者(follower)：跟隨者都是被動的，他們不會傳送任何請求，只是簡單的響應來自領導者或者候選人的請求。

當跟隨者長時間沒接收到領導人的心跳包或候選人的請求投票rpc時（超時），便會成為候選人發起投票，直到成為領導人或收到新領導人的心跳包。

raft 通過選舉乙個領導人，然後全權交給它來管理複製日誌來實現一致性。領導人從客戶端接收日誌條目，把日誌條目複製到其他伺服器上，並且當保證安全性的時候告訴其他的伺服器應用日誌條目到他們的狀態機中。擁有乙個領導人大大簡化了對複製日誌的管理。

在這裡只說一下領導人選舉的整個大致流程：

當follower（伺服器程式啟動時，都是follower）長時間未接受到有效的leader或者candidate的rpcs時，發生超時則會增加自身任期號，成為candidate，然後並行的向集群中的其他伺服器節點傳送請求投票的rpcs，候選人會繼續保持著當前狀態直到以下三件事情之一發生：

每一次選舉都是乙個任期（term），任期由整數表示，單調遞增。每次選舉都會分配一段隨機的超時時間選舉超時時間（eg:150~300ms）,若這段時間內未完成選舉，則任期加1，開啟新一輪的選舉。

詳情戳：raft 協議中文翻譯

raft 協議形象動畫演示

具體的例項：咱們等到開始學習 redis 的 sentinel 時再來述說！！！

當然，副本肯定是容錯技術的唯一手段。那麼總控機如何檢測工作機是否正常吶，主要有如下的兩種協議方法

可以在心跳包上加上其他資訊。問題是如果收不到心跳回應，你如何確定機器是不是發生了故障還是因為網路錯誤吶？？如何解決：租約協議

什麼是租約協議，就是主控給b乙個工牌，這個工牌是有期限的，當期限到了時候，b需要來找主控，主控根據b的工作情況，再次下發乙個工牌給b，如果超過工牌使用期限，b就無法工作，這個工牌就是租約了。

考慮他是如何解決上面提到的那個問題的：

如果網路不好或者發生故障，就會超時。停止服務

這和 心跳包+ 超時，難道不是一樣的嗎？真有意思~~

為了減輕主控伺服器的壓力嗎？

分布式路由協議

路由收斂時間 從網路故障發生到所有路由器 表示式達到一致所需要的時間 路由收斂可能會引起兩個主要問題 路由黑洞和路由迴路。分布式路由協議在常用在控制平面。網路中的涉及 的每乙個節點通過分布式演算法計算推斷各自的 表。這些分布式協議基於兩個原則 1 每個節點向它的鄰居節點報告自己的路由資訊 2 一旦受...

分布式基礎 http協議

一 客戶端和服務端的請求原理 客戶端與服務端互動時將會涉及到協議的內容，通常我們使用的是http https協議。注意http協議是基於傳輸層協議 tcp udp等 之上的應用層協議，而https協議是在tcp udp和http協議之間加了一層ssl tls傳輸協議，http協議不保證安全傳輸，而h...

分布式 分布式鎖

本質是利用redis的setnx 方法的特性來加鎖，setnx 即key不存在則設定key，否則直接返回false，要求在分布式系統中使用同乙個redis服務，以下提供兩種解決方案 1 直接使用redistemplate 這其實並不能完全保證高併發下的安全問題，因為可能在鎖過期之後該執行緒尚未執行完...