分布式锁的设计

痛定思痛。 2022-05-23 03:23 99阅读 0赞

今天群里的小伙伴说有个大二的童鞋就在做分布式锁，我眉头一皱（什么是分布式锁？）于是乎赶紧百度了一番：

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在[分布式系统][Link 1]中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证[一致性][Link 2]，在这种情况下，便需要使用到分布式锁。

然后又百度了一番分布式锁的方案，最简单的最原始的分布式锁方案可能是数据库锁表了，其中我个人感觉最核心的其实是UNIQE KEY

CREATE TABLE `lockedOrder` (
      `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主码',
      `type` tinyint(8) unsigned NOT NULL DEFAULT '0' COMMENT '操作类别',
      `order_id` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的order_id',
      `memo` varchar(1024) NOT NULL DEFAULT '',
      `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
      PRIMARY KEY (`id`),
      UNIQUE KEY `uidx_order_id` (`order_id`) USING BTREE
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的订单';

这张表能完成分布式锁的主要原因正是由于把order\_id设置为了`UNIQUE KEY`，所以同一个订单号只能插入一次。

不过通过学习下面两个方案，我并不推荐使用数据库锁表的方式实现分布式锁。

方案一：使用redis实现分布式锁，redis锁定的原理是利用setnx命令，即只有在某个key不存在情况才能set成功该key，这样就达到了多个进程并发去set同一个key，只有一个进程能set成功。

劣势：劣势就是由于数据在内存中，一旦缓存服务宕机，锁数据就丢失了。像redis自带复制功能，可以对数据可靠性有一定的保证，但是由于复制也是异步完成的，因此依然可能出现master节点写入锁数据而未同步到slave节点的时候宕机，锁数据丢失问题。（redis作者鉴于单点redis作为分布式锁的可能出现的锁数据丢失问题，提出了Redlock算法，这里我不做过多的赘述。）

方案二：使用zookeeper实现分布式锁，zookeeper实现锁的方式是客户端一起竞争写某条数据，比如/path/lock，只有第一个客户端能写入成功，其他的客户端都会写入失败。写入成功的客户端就获得了锁，写入失败的客户端，注册watch事件，等待锁的释放，从而继续竞争该锁。

zookeeper特质：

*  zookeeper支持watcher机制，这样实现阻塞锁，可以watch锁数据，等到数据被删除，zookeeper会通知客户端去重新竞争锁。
 *  zookeeper的数据可以支持临时节点的概念，即客户端写入的数据是临时数据，在客户端宕机后，临时数据会被删除，这样就实现了锁的异常释放。使用这样的方式，就不需要给锁增加超时自动释放的特性了。

所以总结下来如果需要最可靠的分布式锁，还是使用zookeeper会更可靠些。curator-recipes库封装的分布式锁，java应用也可以直接使用。而且如果开始依赖zookeeper，那么zookeeper不仅仅提供了分布式锁功能，选主、服务注册与发现、保存元数据信息等功能都能依赖zookeeper，这让zookeeper不会那么闲置。

如果对分布式锁想要更深入的了解：http://www.weizijun.cn/2016/03/17/聊一聊分布式锁的设计/(讲的很详细)

[Link 1]: https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F
[Link 2]: https://baike.baidu.com/item/%E4%B8%80%E8%87%B4%E6%80%A7