Paxos演算法的通俗理解

Paxos演算法解決的問題是一個分散式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分散式的MySQL資料的強一致性。

Paxos要解決的問題，是分散式系統中的一致性問題。那麼到底什麼是“分散式系統中的一致性問題”呢？在分散式系統中，為了保證資料的高可用，通常，我們會將資料保留多個
副本(replica)，這些副本會放置在不同的物理的機器上。副本要保持一致，那麼，所有副本的更新序列就要保持一致。因為資料的增刪改查操作一般都存在多個客戶端併發操作，
到底哪個客戶端先做，哪個客戶端後做，更新順序要保證。如果不是分散式，那麼可以透過加鎖的方法，誰先申請到鎖誰就先操作，但這就存在單點問題。Paxos協議主要有兩種用法：
一種用法是用來實現全域性的鎖服務或者命名和配置服務，例如Google Chubby以及Apache ZooKeeper。另外一種用法是用它來將使用者資料複製到多個資料中心，例如Google Megastore以及Google Spanner。

在Paxos演算法中，主要有3種角色：
Proposer：提議者
Acceptor：決策者
Learner：最終決策學習者
實現的時候往往採用一組固定數目的Server，每個Server同時擔任上述三個角色。
Paxos演算法分為以下三個階段：
1、Prepare階段
(1)Proposer向大多數Acceptor發起Proposal(epochNo,value)的Prepare請求。
(2)Acceptor收到Prepare請求，如果epochNo比之前接收到的小，直接拒絕；如果epochNo比之前已經接收的大，就將已經接收到的epochNo最大的Proposal返回到Proposer。
(3)Proposer發起的Proposal至少要收到大多數以上的Acceptor的Prepare應答後，才能進入接下來的Accept階段，否則需要重新進行Prepare階段向大多數Acceptor發起Prepare請求。
2、Accept階段：
(1)Proposer收到大多數的Acceptor的Prepare應答後，看Acceptor是否已經有被接受的Proposal。如果沒有已經接受的Proposal，就自己提出一個Proposal，發起Accept請求；如果已經有被接受的Proposal，就從中選出epochNo最大的Proposal，發起對該Proposal的Accept請求。
(2)Acceptor收到請求後，如果該Proposal的epochNo比它最後一次應答Prepare請求的epochNo要大，那麼就接受該請求；否則拒絕該請求。
3、Learn階段：
所有Acceptor接受的Proposal要不斷通知Learner，或者Learner主動去查詢，一旦Learner確認Proposal被大多數的Acceptor接受，那麼表示這個Proposal的Value被Chosen，Learner就可以學習這個Proposal的Value，同時自己的Sever上就不再受理Proposor的請求。

Paxos協議資料同步方式相對於基於傳統1主N備的同步方式有啥區別？
一般情況下，傳統資料庫的高可用都是基於主備來實現，1主1備2個副本，主庫crash後，透過HA工具來進行切換，提升備庫為主庫。在強一致場景下，複製可以開啟強同步，Oracle和Mysql都是類似的複製模式。但是如果備庫網路抖動，或者crash，都會導致日誌同步失敗，服務不可用。為此，可以引入1主N備的多副本形式，我們對比都是3副本的情況，一個是基於傳統的1主2備，另一種基於paxos的1主2備。傳統的1主兩備，進行日誌同步時，只要有一個副本接收到日誌並就持久化成功，就可以返回，在一定程度上解決了網路抖動和備庫crash問題。但如果主庫出問題後，還是要藉助於HA工具來進行切換，那麼HA切換工具的可用性如何來保證又成為一個問題。基於Paxos的多副本同步其實是在1主N備的基礎上引入了一致性協議，這樣整個系統的可用性完全有3個副本控制，不需要額外的HA工具。而實際上，很多系統為了保證多節點HA工具獲取主備資訊的一致性，採用了zookeeper等第三方介面來實現分散式鎖，其實本質也是基於Paxos來實現的。