文章插图
这次，我们站在上帝视角，让听众2改变一下选择 ， 既然话务员2已经被别人收买了，那么干脆避其锋芒，直接向话务员1、3报价 。
文章插图
可想而知，听众2的报价会被两位话务员都认可 。
文章插图
在收到了半数以上话务员的报价认可后，听众2先向话务员1发起点歌请求 。
文章插图
话务员1比对一下报价，嗯，没有问题 ， 更新本地的记录，接受他的点歌请求 。
文章插图
讲道理，现在的形势对听众2真的是一片大好 ， 只要再打个电话给话务员3，就能够成功点歌了 。
但是这个节骨眼上，听众2的室友喊他了，说：听歌多没意思，咱们一起来打一局刀塔吧 。
听众2一想，没毛?。俏蚁炔坏愀枇?。
而这时，听众1回过神来了，他在之前报价阶段可是获得过半数以上的认可的 ， 于是他带着之前被认可的报价打电话进来点歌 。
文章插图
可是在两位话务员那里，记录的最高报价已经升到了两块了，于是听众1的点歌请求会被拒绝 。
文章插图
到这 ， 我们梳理一下，听众1的点歌请求得到了1个接受、2个拒绝 ， 也就是说他的提议没有被过半数以上的话务员接受 。
无奈，听众1只能回到第一阶段 ， 从报价开始再重头走一遍流程 。并且这次，他把报价提升到了3块 。
文章插图
三位话务员收到新的报价请求后，都会表示认可，并且返回自己本地记录的信息 。
文章插图
听众1这一次收到的三条报价认可中，有两条携带了之前被接受的点歌信息 。那么新问题来了 ， 他应该选哪一首歌曲作为自己接下来要点播的歌曲呢？
在这里，听众要遵循的规则其实和话务员一致，他需要在这些返回的报价及歌曲信息中，选择最高报价的歌曲，作为自己的接下来选歌的依据，因此他最终会选择《简单爱》 。
文章插图
最终，在没有其他听众中途打进电话干扰的情况下 ， 三位话务员都会接受听众1的点歌请求 。
文章插图
最终，听众1的点歌请求收到超过半数话务员的接受，于是他确认《简单爱》这首歌会被选中 。
最后前面提到过，Paxos算法中的选举过程就像是一场博弈，场上局势瞬息万变 。
回顾一下上面3条不同的时间线，打进电话顺序的不同、选择的话务员不同，都可能导致最终产生不同的结果 。
而Paxos算法本身，并不关注最终选择的是哪一个结果，它关注的是无论如何，在最后一定要能够达成一个共识 。
当然了，也有可能遇到下面这种无法解决的情况…
文章插图
文章插图
在这种情况下 ， 可能会有两个听众交替报价成功，却提议歌曲失败 ， 形成一个活锁的局面 。如果这样下去，有可能一整天下来，一首歌曲都没有被最终选取成功 。
所以在某些情况下，需要选取一个主提案者，只有主提案者才能和过半的接受者进行通信提出提案 。
说白了，也就是我们常说的话事人 。
文章插图
那么 ， 我们最后再做一个总结，其实在我看来，Paxos算法的关键，就在于后者要认同前者，来避免无休止的争端 。
本文也只是对决议部分的两阶段通过示例进行了说明，并忽略了算法中另一个角色学习者的内容，如果有兴趣的话，大家不妨去看看论文原文 。
毕竟兰伯特大佬都说了：
文章插图
推荐阅读
- SpringCloud整合分布式事务Seata 1.4.1 支持微服务全局异常拦截
- 穿越火线CF怎么改名呢（cf昵称被系统强制改名了)
- MassTransit | .NET 分布式应用框架
- 齐博X1-栏目的调用1
- 云原生分布式 PostgreSQL+Citus 集群在 Sentry 后端的实践
- 微服务系列之分布式日志 ELK
- 华为手环6是什么系统_华为手环6是鸿蒙系统吗
- Blazor组件自做十一 : File System Access 文件系统访问 组件
- ios14.6耗电怎么样_ios14.6系统耗电情况
- 谷歌新AI系统Imagen有点强，输入文本就能生成逼真的图像