swzxsyh

--笔记

0%

分布式锁

发表于 更新于
  • Database
  • Redis
  • Zookeeper

Conceptual

分布式锁是分布式系统中用于协调对共享资源的访问的一种同步机制。它们允许多个进程或线程以互斥的方式协调它们对共享资源的访问，确保一次只有一个进程可以访问该资源，同时确保在发生故障或其他意外事件时释放锁。

这有助于避免竞争条件、死锁和其他同步问题。

DataBase

Pros & Cons

Pros

  • 使用简便

Cons

  • 高并发下性能较差

Code

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `reentrant_name`  varchar(64) NOT NULL DEFAULT '' COMMENT '重入主机与线程信息',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  `unpark_time` timestamp NOT NULL COMMENT '锁失效时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
)
 ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

Redis

Conceptual

  • Redis 有多种锁定方式，包括setnx, redlock, redisson
    • setnx不适合集群redis锁定，多个Redis实例可能导致同一个key同时上锁
    • redlock，通过Key + UUID +TTL方式对每个节点进行上锁
    • redisson集成API，支持redlock并使用Hash+Lua重写算法

Pros & Cons

Pros

  • 以Redisson为例
    • Java API使用简便
    • 支持重入
    • 支持自动续期
    • 支持RedLock算法

Cons

  • 对Java字符串支持相对较差
  • 相对较重
  • TTL时间内循环重试上锁

Zookeeper

Conceptual

在 Zookeeper 当中创建一个持久节点。当第一个客户端想要获得锁时，在持久节下面创建一个临时顺序节点 Lock。之后，Client1 查找 持久节点 下面所有的临时顺序节点并排序，判断自己所创建的节点 Lock 是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。

如果再有一个客户端 Client2 前来获取锁，则在 持久节点 下再创建一个临时顺序节点 Lock2。

3、Client2 查找 持久节点 下面所有的临时顺序节点并排序，判断自己所创建的节点 Lock2 是不是顺序最靠前的一个，结果发现节点 Lock2 并不是最小的。于是，Client2 向排序仅比它靠前的节点 Lock1 注册 Watcher，用于监听 Lock1 节点是否存在。这意味着 Client2 抢锁失败，进入了等待状态，这就形成了一个等待队列。

4、 当任务完成时，Client1 会显示调用删除节点 Lock1 的指令。此时由于 Client2 一直监听着 Lock1 的存在状态，当 Lock1 节点被删除，Client2 会立刻收到通知。这时候 Client2 会再次查询 持久节点 下面的所有节点，确认自己创建的节点 Lock2 是不是目前最小的节点。如果是最小，则 Client2 顺理成章获得了锁。

5、如果说获得锁的 Client1 在任务执行过程中如果崩溃了，则会断开与 Zookeeper 服务端的链接。根据临时节点的特性，相关联的节点 Lock1 会随之自动删除；所以Client2 又收到通知获得了锁。

Pros & Cons

Pros

  • 强一致性
  • 可以实现读写锁
  • Watch机制自动获取锁

Cons

  • 可能因GC等原因导致心跳检测异常，znode可能被删除
  • 性能相对Redis弱