用java实现etcd分布式锁_分布式锁技术造型及为什么要用etcd

分布式锁技术选型

常见的分布式锁，有基于Redis实现，有基于Zookeeper实现，有基于etcd实现。那么，到底哪种更适合用于分布式锁呢？我们做一个对比：

Redis用户分布式锁时，实现简单，市面上也有许多的开源框架。但是从根本上来说，它并不适合于分布式锁。因为分布式锁从业务场景上来说，是CP的，但Redis是AP的。

Zookeeper在实现分布式锁时，依靠的是创建临时节点和watch机制，它的效率和扩展能力都是比较低的，因此，也较少人使用。

etcd是一个Key/Value存储系统，但是它不同于Redis，在一致性和集群方面，借鉴了Zookeeper，使得它的集群能力和一致性能力都是比较强的。在使用方面，又采用restful API这种比较简单的使用方式，有点像ES。因此，我们发现，其实etcd是最适合用来做分布式锁的。

表格中，对etcd的接口类型提供，它可以使用http或grpc。grpc是一个基于http/2，面向移动端的RPC框架。它具备以下一些优势：

1. 双向流，多路复用，高吞吐量。

2. 头部压缩。

3. 跨平台，多语言。

后续，我们会有专门的文章来聊http，grpc等通信协议。

分布式锁业务需求

确定了etcd是比较适合于分布式锁的一种技术，接下来，我们来思考一下，在设计分布式锁时，有哪些需求是需要满足的。可以参考一些常见的分布式锁框架来整理。

1. 强一致性。从业务场景来说，分布式锁一定应该是CP的。

2. 服务高可用，系统稳健。有稳定可靠的集群能力。

3. 锁自动续约和释放。锁可以自动释放或续约，避免死锁或丢锁。

4. 封装性好，接口简单。具备极强的可封装性，对业务代码侵入极小。

5. 可重入。需要实现可重入锁。

6. 统一管理。需要一个统一的管理后台。可以对当前锁的使用进行统一的监控和管理。

基于etcd的分布式锁的基本框架和关键技术

根据上面的业务需求，我们可以描绘出一个基于etcd的分布式锁的基本框架。如下：

分布式锁框架

如图，首先我们需要一个etcd集群和一个监控平台，然后，我们需要封装一个客户端包，供其它微服务方便地接入。客户端中，主要有竞锁，续租，探活，监控等几个主要功能，监控会将运行数据和监控平台进行交互，其它则主要和etcd集群发生交互。

etcd的锁结构，和Redis一样，也是一个key/value对。获取锁时，通过http或grpc结构，向etcd中插入key/value键值对，插入成功则获取锁成功，否则获取锁失败。

服务的续航和自动释放，同样也可以通过像Redis一样，对key设置过期时间，并通过独立线程或协程，采用心跳机制，自动续约。