分布式节点的决策王者——Paxos协议

大家晚上好！今天聊个分布式节点相关的协议——Paxos协议。还是老规矩，聊聊为什么会有这个协议。

————

我们知道分布式节点是一种非常常见的架构，一份数据多份备份。数据有多个副本，分别存放在不同的机器（节点）上。比如，为了高可用，一份数据可能在 A、B、C 三台机器上各存一个副本。那这里出现了一个问题，如果我们要修改这份数据，我们如何保证三个节点都保持同样的修改顺序，如果某一节点网络延迟、断线等等，他还能知道自己执行了什么、将要执行什么吗？如果它判断错了，就会产生极大的混乱！三份数据如果内容不一样，那是不是会产生很多影响实际业务的问题呢？

所以就产生了 Paxos协议。这个协议就是为了在分布式节点中保持‘唯一意见’，在线的和即使因某些情况断线的恢复后会通过主动询问和学习从而也遵从这个 ‘统一意见’、‘统一顺序’。今天讲实现过程。

————

我们来看看Paxos协议是如何实现的~先来看看我画的图。

首先我们可以看到这个图有两个对象，一个是Proposer，一个是Acceptor。可以看到几个Acceptor是圈起来的，这里表明一组节点，每个内容都是一样的，只不过编码不同。而Proposer则是‘提案者’。这两个对象记到这里就可以。

我们代入例子去理解这个协议。如果有三个人要去百度搜索个东西，分别是Proposer-1、Proposer-2、Proposer-3，我们可以看到紫色圆圈步骤1，是P1(Proposer-1缩写）发话了：我要发个提案，编号为1。P1这句话发给分布式节点，大家一合计，我们也没收到其它的比编号为1还大的，我们三个节点有两个节点都同意，超过一半了，你发出来吧。P1就拥有提案权了，它在凌晨1:00:12发起编号为1，值为苹果的提案。分布式节点们正式收到P1的提案了，它们又一合计，我们还没收到编号比1大的提案，于是正式接受了编号为1，值为苹果的记录，而且偷偷写在本子上（持久化数据）。

P2姗姗来迟，她先是在分布式节点面前晃了一下：我要发个提案，编号为2。分布式节点们你看看我，我看看你，然后说：我们不能接受编号比1还小的提案了，不过你是2，我们可以接受，但我必须和你说，根据Paxos协议规定，你的编号可以使用，但我们的值已经有了，是【苹果】，你只能继承【苹果】。P2一想，那我原先的值 香蕉 不能带走了呀，好吧好吧，那我发起提案(2,苹果）。分布式节点们收到提案后就都同意了。

那我有个问题，如果Acceptor1在还未收到提案2时断线了，怎么办？答案是在Acceptor1中发起提案时再次学习到【苹果】值。这里你又要发起疑问，就是Acceptor怎么能发起提案呢。请注意上面的图只是一种罕见的结构，更多的结构是在Proposer和accptor都是轮流当的，也就是每个服务器节点（进程）都同时扮演着Proposer、Acceptor和Learner三个角色。这个有点篇幅大。大家先聊到Paxos的具体过程就可以！！

————

那Paxos常常应用在哪里呢？分布式架构分布式架构分布式架构！！

关注我，持续输出高质量内容。

谢谢你看到最后，祝你生活愉快。

如果觉得我写得好，欢迎关注我更多技术文章，在公众号：会用数据库 

谢谢！

——生活最好的那条路，是自己主动选择的。