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來實現的。
