spring mvc工作原理_redis aof_paxos 算法(3)

4、重新加入的节点可能会扰乱前面的paxos过程，因此强制Node在重新加入前必须等待M秒，因为M > T，所以只要等待M秒便可以越过本次paxos选举。其实不能从理论上完全保证PaxosLease能正确执行。重要的是重加入后不能立即参加paxos过程。在实际中因为选举的过程非常快，节点重加入的过程也可监控，这些理论上的错误是很难发生的。

PaxosLease的正确性是有Paxos算法保证的，PaxosLease只是在Paxos的基础上限定了一个时间。在时间T之内，任何Node都不能申请lease，因此master宕机后重新选择master的最大时间为T，也即服务不可用的最大时间为T。

T设的过小会减少服务不可用的时间，但会产生更多的内部消息；设的过大内部消息减少，但会导致更长的宕机时间。

PaxosLease是一个节点之间不存在依赖的简洁的选举算法，就像其论文所说每个节点都有两个状态：

我不是master，也不知道谁是master

我是master

正因为如此，PaxosLease的缺点就是无法做到负载均衡，无法按权重选择master。

Lease 机制

Lease机制是最重要的分布式协议，广泛应用于各种实际的分布式系统中。

Lease通常定义为：颁发者在一定期限内給予持有者一定权利的协议。

Lease 表达了颁发者在一定期限内的承诺，只要未过期颁发者必须严格遵守 lease 约定的承诺；

Lease 的持有者在期限内使用颁发者的承诺，但 lease 一旦过期必须放弃使用或者重新和颁发者续约。

参考资料 #12

paxos是对一个值达成一致，multi-paxos是运行多个paxos instance来对多个值达成一致，每个paxos instance对一个值达成一致。在一个支持多写并且强一致性的系统中，每个节点都可以接收客户端的写请求，生成redo日志然后开始一个paxos instance的prepare和accept过程。这里的问题是每条redo日志到底对应哪个paxos instance。

Multi Paxos基于Basic Paxos，将原来2-Phase过程简化为了1-Phase，从而加快了提交速度。Multi Paxos要求在各个Proposer中有唯一的Leader，并由这个Leader唯一地提交value给各Acceptor进行表决，在系统中仅有一个Leader进行value提交的情况下，Prepare的过程就可以被跳过，而Leader的选举则可以由Paxos Lease来完成。

参考资料：#15

工程实践的角度重新描述了Paxos，使其更贴近应用场景

就是Client的提案由Coordinator进行，Coordinator存在多个，但只能通过其中被选定Leader进行；提案由Leader交由Server进行表决，之后Client作为Learner学习决议的结果。paxos 算法

这种方式更多地考虑了Client/Server这种通用架构，更清楚地注意到了Client既作为Proposer又作为Learner这一事实。

下面是Classic Paxos交互图：

下面是Fast Paxos的交互图：

Fast Paxos基本是本着乐观锁的思路：如果存在冲突，则进行补偿。其中Leader起到一个初始化Progress和解决冲突的作用，如果Progress一直执行良好，则Leader将始终不参与一致性过程。

因此Fast Paxos理论上只需要2个通信步骤，而Classic Paxos需要3个，但Fast Paxos在解决冲突时有至少需要1个通信步骤，在高并发的场景下，冲突的概率会非常高，冲突解决的成本也会很大。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-28611-3.html