如何使用Etcd来完成选举

背景

在某个项目中，需要使用选举的功能来由Leader完成一些类似任务分配的工作。在最初的版本是使用Zookeeper配合curator框架来实现的，curator的api相对来说也比较直观，文档也比较齐全，实现起来并不耗费多少力气。可是由于公司的Zookeeper集群版本相对较低，curator不得不使用低版本来兼容，运行一段时间之后碰上了一些低BUG的，添加了一些兜底的保障来完善选举流程。然而，公司的Etcd集群版本相对较新，便萌生了使用Etcd来替代Zookeeper的想法。

Etcd Election API

Election API是在V3版本才出现的，使用文档寥寥无几，若是使用jetcd的同学，那就几乎找不到什么完整的例子了。Election API一共包含了5个接口：

• Campaign ： 用于发起选举
• Proclaim：用于Leader发布新的Value
• Leader：返回选举的Leader
• Observe：订阅Leader的Value值
• Resign：释放主权

在使用Etcd Election中，是用字符串来标识一次选举的，实际上这个字符串是用作业Etcd Key的Prefix。参与选举时除了指定选举标识外，还可以指定将要发布的内容。当成功当选以后，这个发布的值会被记录在参与选举的KV中，同时发布到所有通过Observe API订阅了选举的节点上。当需要更新这个值时就可以使用Proclaim来发布新的值，同理订阅者都会收到这个值的更新。
值得一提的有两件事。
第一，每次选举都要带上一个Lease，可以简单的理解为获得主权的节点并不是永久获得主权的，Lease过期，主权自动释放，由于选举实际上就是创建一个KV，KV上关联了Lease，Lease过期，KV销毁，主权自然释放，当然可以用Keep Alive持续保持主权。
第二，未成功获取主权的节点，直到此次选举出来的主节点释放掉主权后，才能从Campaign API中获取到返回值。和Zookeeper不一样的是，Etcd一次选举只选出一个主，而Zookeeper主释放后，剩下的节点会重新竞争。表现就是Campaign函数返回结果以后，并不能直接断定自己获取到了主权，因为可能返回的LeaderKey已经失效了。

JETCD 使用

结合上面对于API的解释，我们可以很容易的写出下面的代码

 CompletableFuture<LeaseGrantResponse> grant = client.getLeaseClient().grant(properties.getElectionLeaseTTL());
                LeaseGrantResponse leaseGrantResponse = grant.get();
                CompletableFuture<CampaignResponse> campaign = client
                        .getElectionClient()
                        .campaign(electionName,
                                leaseGrantResponse.getID(),
                                ByteSequence.from("", StandardCharsets.UTF_8));
                CampaignResponse campaignResponse = campaign.get();
                confirmLeaderResponse = client.getElectionClient().leader(electionName).get(getOperationTimeout() * 5, TimeUnit.MILLISECONDS);
                if (!confirmLeaderResponse.getKv().getKey().toString(StandardCharsets.UTF_8)
                        .equals(campaignResponse.getLeader().getKey().toString(StandardCharsets