Consul实现leader election的过程是这样的过程（这个过程主要翻译自Consul的文档）：
- 1.所有客户端都竞争操作一个key，比如这个key是service//leader。
- 2.所有客户端创建一个session，创建成功后每个客户端都会获得一个sessionid。
- 3.所有想成为leader的客户端都试图去更新这个key，并且所有客户端都acquire=这个请求参数。acquire是consul在kv存储的api上扩展的功能。acquire的意思是获取更新这个key的锁，session是我们步骤2中每个客户端各自创建的session。如果请求返回true，则这个客户端获得了锁，并且成功的更新了这个key，称为了leader。如果返回false，则其他客户端获得了锁。
- 4.如果没有获得锁，则watch这个key，如果这个发生变化，并且这个key中session信息为空，则所有当前没有客户端获得锁，重复步骤3获取锁。
比较Zookeeper和Consul实现leader election的方式，我们可以看出，Zookeeper提供sequence这种特性，而Consul本身就提供了锁的特性。我们可以基于sequence的特性，分别构建分布式锁和选主（2者本质是相同的）。Consul利用锁机制实现选主。
Zookeeper的选主是利用了sequence的特性保证同时连接上来的多个客户端都分配一个不重复序号。大家按序号的大小，从小到大依次称为leader。因为每个客户端watch的是比自己序号小的那个节点，当leader失效时，只有一个备选会收到通知。也就是不会出现群惊现象。
Consul保证同时连接上来的多个客户端只有一个可以获得锁，其他客户端不会获得锁。但当前leader失效时，所有其他的客户端都会收到通知，再一起来竞争锁。从这一点来说没有Zookeeper实现的优雅。
