etcd 操作并发 锁_Etcd分布式锁：cp分布式锁的最佳实现

引言

目前自研的Redis分布式锁，已可满足大部分场景(非公平+可自动续期+可重入的分布式锁)，可投入生产环境的单机环境中使用。但是因为是基于Redis单机的环境，只能用于并发量并不高的场景。随着接入的业务场景扩大，Redis单机已经变得不可靠了，那么接下来给我们的选择只有两种： 1、Redis单机改为集群。 2、改用其他基于一致性算法的实现方式。

方案1有先天性的缺陷，redis集群无法保证一致性问题，在master节点宕机的瞬间，master和slave节点之间的数据可能是不一致的。这将会导致服务a从master节点拿到了锁a，然后master节点宕机，在slave节点尚未完全同步完master的数据之前，服务b将从slave节点上成功拿到同样的锁a。

而在其他基于一致性算法的实现方式上，zk和ectd是不错的选择。然后考虑到zk已廉颇老矣，我们选择了ectd这个后起之秀。

由于在分布式锁的场景内，我们更关注的是锁的一致性，而非锁的可用性，所以cp锁比ap锁更可靠。

设计思路

etcd引入了租约的概念，我们首先需要授予一个租约，然后同时设置租约的有效时间。租约的有效时间我们可以用来作为锁的有效时间。

然后我们可以直接调用etcd的lock功能，在指定的租约上对指定的lockName进行加锁操作。如果当前没有其他线程持有该锁，则该线程能直接持有锁。否则需要等待。这里我们可以将timeout的时间设置为锁的等待时间来实现竞争锁失败等待获取的过程。当然由于网络波动等问题，我建议timeout的时间最少设置为500ms(或你们认为合理的数值)。

然后解锁的过程，我们放弃了etcd的unlock操作，而直接使用了etcd的revoke操作。之所以没采用unlock操作，一是因为unlock所需要的参数是上一步lock操作返回的lockKey，我们并不希望多维护一个字段，二是因为我们最终会执行revoke操作，而revoke操作会将该租约下的所有key都失效&