分布式锁设计

Myth丶恋晨 2022-11-11 13:08 98阅读 0赞

### 文章目录 ###

*   *   *   *  （1）介绍
             *  （2）单节点上实现分布式锁
             *  （3）Redis超时解锁问题分析
             *  （4）Redis分布式锁服务的一个问题
             *  （5）乐观锁
             *  （6）分布式锁设计总结

#### （1）介绍 ####

我们知道，在多线程情况下访问一些共享资源需要加锁，不然就会出现数据被写乱的问题。在分布式系统下，这样的问题也是一样的。只不过，我们需要一个分布式的锁服务。对于分布式的锁服务，一般可以用数据库 DB、Redis 和 ZooKeeper 等实现。不管怎么样，分布式的锁服务需要有以下几个特点。  
安全性（Safety）：在任意时刻，只有一个客户端可以获得锁（排他性）。  
避免死锁：客户端最终一定可以获得锁，即使锁住某个资源的客户端在释放锁之前崩溃或者网络不可达。  
容错性：只要锁服务集群中的大部分节点存活，Client 就可以进行加锁解锁操作。

#### （2）单节点上实现分布式锁 ####

![在这里插入图片描述][20210320104409483.png]  
主要依靠上述命令，该命令仅当 Key 不存在时（NX保证）set 值，并且设置过期时间 3000ms （PX保证），值 my\_random\_value 必须是所有 client 和所有锁请求发生期间唯一的

#### （3）Redis超时解锁问题分析 ####

问题：Client 端把锁占住不释放，然后，Redis 在超时后把其释放掉  
注意事项：如果通过Redis构建分布式锁，但是设置的Value是固定的就会导致当一个原先获得锁的Client在锁超时后。再次解锁了却解锁了其他进程的锁，所以在解锁时需要设置通过唯一标识来作判断保证释放的是自己的锁  
关于 value 的生成，官方推荐从 /dev/urandom 中取 20 个 byte 作为随机数。或者采用更加简单的方式，例如使用 RC4 加密算法在 /dev/urandom 中得到一个种子（Seed），然后生成一个伪随机流。  
也可以采用更简单的方法，使用时间戳 + 客户端编号的方式生成随机数。Redis 的官方文档说：“这种方式的安全性较差一些，但对于绝大多数的场景来说已经足够安全了”。

#### （4）Redis分布式锁服务的一个问题 ####

注意，虽然 Redis 文档里说他们的分布式锁是没有问题的，但其实还是很有问题的。尤其是上面那个为了避免 Client 端把锁占住不释放，然后，Redis 在超时后把其释放掉。不知道你怎么想，但我觉得这事儿听起来就有点不靠谱。

1、如果 Client A 先取得了锁。  
2、其它 Client（比如说 Client B）在等待 Client A 的工作完成。  
3、这个时候，如果 Client A 被挂在了某些事上，比如一个外部的阻塞调用，或是 CPU 被别的进程吃满，或是不巧碰上了 Full GC，导致 Client A 花了超过平时几倍的时间。  
4、然后，我们的锁服务因为怕死锁，就在一定时间后，把锁给释放掉了。  
5、此时，Client B 获得了锁并更新了资源。  
6、这个时候，Client A 服务缓过来了，然后也去更新了资源。于是乎，把 Client B 的更新给冲掉了。  
7、这就造成了数据出错。

解决方案：  
1、锁服务需要有一个单调递增的版本号。  
2、写数据的时候，也需要带上自己的版本号。  
3、数据库服务需要保存数据的版本号，然后对请求做检查。  
如果使用 ZooKeeper 做锁服务的话，那么可以使用 zxid 或 znode 的版本号来做这个 fence 版本号。

#### （5）乐观锁 ####

使用数据版本（Version）记录机制，即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现的。当读取数据时，将 version 字段的值一同读出，数据每更新一次，对此 version 值加一。  
当我们提交更新的时候，数据库表对应记录的当前版本信息与第一次取出来的 version 值进行比对。如果数据库表当前版本号与第一次取出来的 version 值相等，则予以更新，否则认为是过期数据

#### （6）分布式锁设计总结 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70]

[20210320104409483.png]: /images/20221022/bd180b2dee744915a1cbdb339a463430.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210320104844171.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ==,size_16,color_FFFFFF,t_70