一篇文了解分布式队列编程：从模型、实战到优化

令人遗憾的是,除非工程师们自己在消费者实例里面实现Paxos等算法,并在每次消息处理之前都执行领导人选举.否则,理论上讲,没有方法可以保障在同一个时刻只有一个领导者.而对每个消息都执行一次领导人选举,显然性能不可行.

实际工作中,最容易出现的问题时机发生在领导人交接过程中,即前任领导人实例变成辅助实例,新部署实例开始承担领导人角色.为了平稳过渡,这两者之间需要有一定的通讯机制,但是,无论是网络分区(Network partition)还是原领导人服务崩溃都会使这种通讯机制变的不可能.

对于完整性和一致性要求很高的系统,我们需要在选举制度和交接制度这两块进行优化.

领导人选举架构

典型的领导人选举算法有Paxos、ZAB( ZooKeeper Atomic Broadcast protocol).为了避免重复造轮子,建议采用ZooKeeper的分布式锁来实现领导人选举.典型的ZooKeeper实现算法如下：

Let ELECTION be a path of choice of the application. To volunteer to be a leader:

1.Create znode z with path “ELECTION/guid-n_” with both SEQUENCE and EPHEMERAL flags;

2.Let C be the children of “ELECTION”,and i be the sequence number of z;

3.Watch for changes on “ELECTION/guid-n_j”,where j is the largest sequence number such that j < i and n_j is a znode in C;

Upon receiving a notification of znode deletion:

1.Let C be the new set of children of ELECTION;

2.If z is the smallest node in C,then execute leader procedure;

3.Otherwise,watch for changes on “ELECTION/guid-n_j”,where j is the largest sequence number such that j < i and n_j is a znode in C;

领导人交接架构

领导人选举的整个过程发生在ZooKeeper集群中,各个消费者实例在这场选举中只充当被告知者角色(Learner).领导人选举算法,只能保证最终只有一个Leader被选举出来,并不保障被告知者对Leader的理解是完全一致的.

本质上,上文的架构里,选举的结果是作为令牌(Token)传递给消费者实例,消费者将自身的ID与令牌进行对比,如果相等,则开始执行消费操作.所以当发生领导人换届的情况,不同的Learner获知新Leader的时间并不同.

（编辑：好传媒网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!