文章插图
听众1这一次收到的三条报价认可中，有两条携带了之前被接受的点歌信息 。那么新问题来了，他应该选哪一首歌曲作为自己接下来要点播的歌曲呢？
在这里，听众要遵循的规则其实和话务员一致，他需要在这些返回的报价及歌曲信息中，选择最高报价的歌曲，作为自己的接下来选歌的依据，因此他最终会选择《简单爱》 。
文章插图
最终，在没有其他听众中途打进电话干扰的情况下，三位话务员都会接受听众1的点歌请求 。
文章插图
最终，听众1的点歌请求收到超过半数话务员的接受，于是他确认《简单爱》这首歌会被选中 。
最后前面提到过，Paxos算法中的选举过程就像是一场博弈，场上局势瞬息万变 。
回顾一下上面3条不同的时间线，打进电话顺序的不同、选择的话务员不同，都可能导致最终产生不同的结果 。
而Paxos算法本身，并不关注最终选择的是哪一个结果，它关注的是无论如何，在最后一定要能够达成一个共识 。
当然了，也有可能遇到下面这种无法解决的情况…
文章插图
文章插图
在这种情况下，可能会有两个听众交替报价成功，却提议歌曲失败，形成一个活锁的局面 。如果这样下去，有可能一整天下来，一首歌曲都没有被最终选取成功 。
所以在某些情况下，需要选取一个主提案者，只有主提案者才能和过半的接受者进行通信提出提案 。
说白了，也就是我们常说的话事人 。
文章插图
那么，我们最后再做一个总结，其实在我看来，Paxos算法的关键，就在于后者要认同前者，来避免无休止的争端 。
本文也只是对决议部分的两阶段通过示例进行了说明，并忽略了算法中另一个角色学习者的内容，如果有兴趣的话，大家不妨去看看论文原文 。
毕竟兰伯特大佬都说了：
文章插图
论文原文：
http://lamport.azurewebsites.net/pubs/paxos-simple.pdf
文章插图
作者简介，码农参上，一个热爱分享的公众号，有趣、深入、直接，与你聊聊技术 。欢迎添加好友，进一步交流 。
经验总结扩展阅读
- 儿童风湿免疫系统疾病症状
- 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系统耗电情况