一篇带给你etcd与分布式锁

2021-05-19 08:12:39可以提供分布式锁功能的组件有多种，但是每一种都有自己的脾气与性格。至于选择哪一种组件，则要看数据对业务的重要性，数据要求强一致性推荐支持CP的etcd、zookeeper，数据允许少量丢失、不要求强一致性的推荐支持AP的redis。

1. 实现分布式锁的组件们

在分布式系统中，常用于实现分布式锁的组件有：Redis、zookeeper、etcd，下面针对各自的特性进行对比：

由上图可以看出三种组件各自的特点，其中对于分布式锁来说至关重要的一点是要求CP。但是，Redis集群却不支持CP，而是支持AP。虽然，官方也给出了redlock的方案，但由于需要部署多个实例(超过一半实例成功才视为成功)，部署、维护比较复杂。所以在对一致性要求很高的业务场景下(电商、银行支付)，一般选择使用zookeeper或者etcd。对比zookeeper与etcd，如果考虑性能、并发量、维护成本来看。由于etcd是用Go语言开发，直接编译为二进制可执行文件，并不依赖其他任何东西，则更具有优势。本文，则选择etcd来讨论某些观点。

2. 对于分布式锁来说AP为什么不好

在CAP理论中，由于分布式系统中多节点通信不可避免出现网络延迟、丢包等问题一定会造成网络分区，在造成网络分区的情况下，一般有两个选择：CP or AP。

① 选择AP模型实现分布式锁时，Client在通过集群主节点加锁成功之后，则立刻会获取锁成功的反馈。此时，在主节点还没来得及把数据同步给从节点时发生down机的话，系统会在从节点中选出一个节点作为新的主节点，新的主节点没有老的主节点对应的锁数据，导致其他client可以在新的主节点上拿到相同的锁。这个时候，就会导致多个进程/线程/协程来操作相同的临界资源数据，从而引发数据不一致性等问题。

② 选择CP模型实现分布式锁，只有在主节点把数据同步给大于1/2的从节点之后才被视为加锁成功。此时，主节点由于某些原因down机，系统会在从节点中选取出来数据比较新的一个从节点作为新的主节点，从而避免数据丢失等问题。

所以，对于分布式锁来说，在对数据有强一致性要求的场景下，AP模型不是一个好的选择。如果可以容忍少量数据丢失，出于维护成本等因素考虑，AP模型的Redis可优先选择。

3. 分布式锁的特点以及操作

对于分布式锁来说，操作的动作包含：

4. 关于etcd

官方文档永远是最好的学习资料，官方介绍etcd如是说：

分布式锁仅是etcd可以实现众多功能中的一项，服务注册与发现在etcd中用的则会更多。

官方也对众多组件进行了对比，并整理如下：

通过对比可以看出各自的特点，至于具体选择哪一款，你心中可能也有了自己的答案。

5. etcd实现分布式锁的相关接口

对于分布式锁，主要用到etcd对应的添加、删除、续约接口。

6. etcd实现分布式锁代码示例

总结

可以提供分布式锁功能的组件有多种，但是每一种都有自己的脾气与性格。至于选择哪一种组件，则要看数据对业务的重要性，数据要求强一致性推荐支持CP的etcd、zookeeper，数据允许少量丢失、不要求强一致性的推荐支持AP的Redis。