当前位置：首页 > news >正文

业界内分布式锁

技术主题

在分布式系统中，面对分布式微服务日益流行的场景，分布式锁一直是分布式系统老生常谈的内容。分布式锁可以防止用户重复点击，对于电商场景中，分布式锁可以防止用户重复下单，给用户带来更好的体验。

通过在Redis中存储一个唯一的key，利用Redis的原子性操作来实现锁的获取和释放

利用Zookeeper的节点临时性和唯一性特点，在一个节点上创建一个临时节点表示锁的占用状态，释放锁时直接删除该节点

通过在数据库中创建一张表，将表的相关信息作为表的字段，通过事务的控制来实现锁的获取和释放

Redis操作必须是原子的：获取锁和释放锁的Redis操作必须是原子的，可以使用Redis的setnx命令实现。它可以原子地执行一次 SET 命令，当且仅当 key 不存在，可以设置成功。
设置过期时间：为避免死锁，需要设置锁的过期时间，若处理业务超时导致锁未被释放，则其他节点可以重新竞争获取锁。使用Redis的expire命令可以设置key的过期时间。
避免误删：为避免误删其他线程的锁，建议在删除前先判断锁是否属于自己。尽管不同线程生成的随机字符串保持一定的唯一性，但是无法完全避免重复。

ZooKeeper操作必须是原子的：获取锁和释放锁的ZooKeeper操作必须是原子的，可以使用ZooKeeper的create命令实现。它可以原子地创建一个唯一且临时的节点。
设置临时节点：在ZooKeeper中创建一个临时节点，表示锁的占用状态。当该节点的客户端断开连接或删除该节点时，ZooKeeper将自动清除该节点。
利用顺序号：在创建临时节点时，可以利用ZooKeeper中的顺序号进行排序，使得节点可以按照一定的顺序排列。其他客户端在同样的目录下依照节点顺序创建临时节点，获得锁的客户端是首个创建临时节点的客户端。
避免死锁：由于删除节点操作可以避免死锁，因此在释放锁的时候需要删除该节点。如果释放锁的时候出现异常导致无法删除节点，可以设置一个超时时间，让ZooKeeper自动删除该节点。
处理异常情况：在分布式系统中，可能会出现各种异常情况，比如网络异常、ZooKeeper节点宕机等情况，需要对这些异常情况进行处理。通常的做法是捕获异常并释放锁。

基于数据库乐观锁实现分布式锁的方法是，为每个需要锁定的资源在数据库中创建一个对应的记录，记录包含以下信息：

其中，owner、last_lock_time 和 version 可以使用数据库的行版本号实现，而资源名称是唯一的。

实现步骤如下：

UPDATE lock_table SET owner=<当前线程标识>, last_lock_time=NOW(), version=version+1 
WHERE resource=<资源名称> AND owner IS NULL;

该语句会尝试更新 lock_table 表中指定资源的记录，并将 owner 设置为当前线程的标识。如果更新成功，则表示当前线程获取了锁；如果更新失败，则表示有其他线程正在持有该资源的锁。

UPDATE lock_table SET owner=NULL, last_lock_time=NOW(), version=version+1 
WHERE resource=<资源名称> AND owner=<当前线程标识> AND version=<当前版本号>;

该语句会尝试将持有资源锁的线程标识和版本号更新为 NULL 和当前版本号+1。如果更新成功，则表示当前线程成功释放了锁；如果更新失败，则表示要么该资源并没有被当前线程锁定，要么在锁定期间该资源的版本号已经被修改了。

需要注意的是，由于乐观锁是基于数据版本号的，因此在高并发情况下，会有一定的冲突率，需要在应用程序中进行重试或回退等操作来保证锁定操作的可靠性。另外，该实现方案也需要确保数据库的事务隔离级别为 SERIALIZABLE，以避免并发情况下的数据不一致性问题。

数据库的被关锁
此外，MySQL 还支持通过 SELECT FOR UPDATE 或 SELECT … LOCK IN SHARE MODE 语句来实现悲观锁。例如：

SELECT field1, version FROM your_table WHERE id = your_id FOR UPDATE;

该语句会将该记录上锁，防止其他事务修改该记录，从而实现悲观锁的效果。在 MySQL 中，悲观锁机制使用的是表锁和行锁，因此在高并发情况下，也需要注意锁冲突导致的性能问题。