最近也把一致性協議大概看了一些，這篇主要是總結，不會貼太多的細節，想要了解細節的，可以百度，多的很；

協議只是在演算法上指明瞭方向，需要做哪幾點，實際工程化還是需要做很多優化，像很多的產品裡面，都是基於實際情況做了很大改動的；

一、Paxos

有人說，其他的一致性協議，都是Paxos的一個特例，我覺得說得挺對的，因為Paxos說的確實抽象，哈哈；

兩大步驟：準備和提交（這兩大步驟貫穿其他一致性協議始終），消息有消息按照編號遞增順序發展；

三大角色：proposal（提出建議，多個）、acceptor（接受建議，多個）、learner（學習者，其實就是後臺保證達成一致的信息都達到所有節點），這三個角色是邏輯概念，實際部署可以是一個實體，大家一定要遵循協議，不然就有拜占庭將軍問題；

關鍵點：大多數，就可以保證節點故障後，至少有一個節點知曉上一輪次結論；

1、準備：

1.1、Proposal對Acceptor說：「大家都聽我說，我給大家100塊」；

1.2、Acceptor對Proposal說：「好呀好呀，我聽你的，別人還沒有提議呢」，同時記下當前報價最高是100塊，本地沒有記錄其他對Proposal的承諾；

Proposal在收到半數以上Acceptor回應後，進入第二步，否則繼續第一步（提高報價），或者停止；

2、提交：

2.1、Proposal對Acceptor說：「我要用100塊把牆刷成白色」；

2.2、Acceptor對Proposal說：「好的，我記下來」，同時記下當前已經對Prorosal承諾了100塊刷 白色；

Learner就會使用同樣的流程，將這個結果傳播；

異常流程：

1.2中，Acceptor如果已經收到報價更高的請求，則拒絕當前報價；如果已經對Proposal承諾，則將承諾的信息傳回給Proposal，如，我已經接受了張三99塊錢將牆刷成紅色的請求；

2.1中，Proposal必須遵守規則，如果沒有收到Acceptor半數以上的回應，就重試第一步或者取消；

否則，就必須檢查這些消息中是否攜帶了承諾，如果沒有，那我就發「我要用100塊把牆刷成白色」；

如果有承諾，如上，那就選擇金錢數（編號）最大的承諾，發送給所有acceptor，就是「我要用99塊把牆刷成紅色」；

先寫這麼多，要去拿小孩奶粉了，待會補充

推薦閱讀：

相關文章