下面的问题是严肃的而不是无聊的。我缺乏分布式系统的经验，但我确实了解 Basic Paxos 的工作原理以及领导者选择为何有用。不幸的是，我的理解还不够深入，无法理解下面的问题。
在论文交易提交共识，第 8 页（链接 PDF 的第 11 页）中，我们有以下声明。
选择一个独特的领导者相当于解决了共识 问题。
如果这个说法属实，并且 Paxos 的目的就是达成共识，为什么 Paxos 本身不普遍用于领导者选举？
此外，同一篇论文还认可了《稳定领导者选举》论文中描述的领导者选举算法。 如果两个问题是等价的，并且同一篇论文支持不同的领导者选举算法，
为什么不使用另一种算法来解决普遍共识问题，而是使用 Paxos？
用于领导者选举。在具有领导者的 paxos 变体中（例如 Multi-paxos、Raft），领导者是由 Paxos 实例选择其数据的节点，或者是在自己的转换中选举领导者（有些人使用术语 Paxos 实例；我更喜欢将共识算法视为在分布式有限状态机中选择转换。）
所有正确的共识算法都可以映射到Basic Paxos，但每种算法都针对不同的事情进行了优化。其中包括 Multi Paxos、Raft、ZAB、Vertical Paxos、Cheap Paxos 和 Chain Replication。 （后三种——以及所有只需要 failure_tolerance+1 节点的共识算法——也需要另一个共识系统来重新配置。但我离题了。）
稳定领导者选举论文不仅仅是Paxos：它包括一个故障检测器（粗略地看，这是一个基于租赁的领导模型。）因此，它比Basic Paxos更昂贵。 在我维护的需要领导者的系统中，故障检测器将利用共识协议来废黜/选举领导者，但除此之外，它们是完全独立的协议。
我会阅读论文，但我可以从稳定领袖选举论文中得到的是，这只是一个概念。他们首先介绍它是什么，然后介绍算法如何做到这一点。当他们介绍算法时，他们再次引用了 Paxos。 （但这只是浏览纸张，仅此而已）。
使用Basic Paxos效率低下：
多个并发提议者，很可能发生冲突和重启每个选择的值进行 2 轮 RPC（准备、接受）
例如：租赁
租赁是最广泛使用的领导者选举机制，它们相对容易理解和实现，并且提供内置的容错能力。租赁通过存储当前领导者的单个数据库来工作。然后，租约要求领导者定期发出心跳以表明它仍然是领导者。如果现有领导者在一段时间后无法心跳，其他领导者候选人可以尝试接管。