分布式锁 🔒

分布式锁 🔒

MySQL 分布式锁

表记录

CREATE TABLE `database_lock` (
	`id` BIGINT NOT NULL AUTO_INCREMENT,
	`resource` int NOT NULL COMMENT '锁定的资源',
	`description` varchar(1024) NOT NULL DEFAULT "" COMMENT '描述',
	PRIMARY KEY (`id`),
	UNIQUE KEY `uiq_idx_resource` (`resource`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='数据库分布式锁表';

获取锁：

INSERT INTO database_lock(resource, description) VALUES (1, 'lock');

释放锁的时，可以删除这条数据：

DELETE FROM database_lock WHERE resource = 1;

缺点：

  • 这种锁没有失效时间，一旦释放锁的操作失败就会导致锁记录一直在数据库中，其它线程无法获得锁。这个缺陷也很好解决，比如可以做一个定时任务去定时清理。
  • 这种锁的可靠性依赖于数据库。建议设置备库，避免单点，进一步提高可靠性。
  • 这种锁是非阻塞的，因为插入数据失败之后会直接报错，想要获得锁就需要再次操作。如果需要阻塞式的，可以弄个for循环、while循环之类的，直至INSERT成功再返回。
  • 这种锁也是非可重入的，因为同一个线程在没有释放锁之前无法再次获得锁，因为数据库中已经存在同一份记录了。想要实现可重入锁，可以在数据库中添加一些字段，比如获得锁的主机信息、线程信息等，那么在再次获得锁的时候可以先查询数据，如果当前的主机信息和线程信息等能被查到的话，可以直接把锁分配给它。

悲观锁

我们必须关闭 MySQL 数据库的自动提交属性，因为 MySQL 默认使用autocommit 模式，也就是说，当你执行一个更新操作后，MySQL 会立刻将结果进行提交。

mysql> SET AUTOCOMMIT = 0;

获取锁：

SELECT * FROM database_lock WHERE id = 1 FOR UPDATE;

释放锁：

COMMIT;

MySQL InnoDB 引起在加锁的时候，只有明确地指定主键(或索引)的才会执行行锁 (只锁住被选取的数据)，否则 MySQL 将会执行表锁(将整个数据表单给锁住)。在悲观锁中，每一次行数据的访问都是独占的，只有当正在访问该行数据的请求事务提交以后，其他请求才能依次访问该数据，否则将阻塞等待锁的获取。

Redis 分布式锁

Redis 实现的分布式锁，请阅读 Redis 分布式锁

ZooKeeper 分布式锁

最简单锁实现

  • lock: 创建一个带有 EPHEMERAL 标志的 designated znode，创建成功，锁成功；否则，客户端可以设置上 watch 标志，当当前的 leader 挂掉的时候，即时地获得通知。
  • unlock: 客户端显示地删除 znode 的时候，或者客户端挂掉的时候，锁自动释放。znode 被删除的时候，其他想要获取锁的客户端可以获取到通知。

缺点：

  • herd effect (羊群效应)：如果有许多客户端等待获取锁，那么当锁被释放时，他们都会争夺锁，即使只有一个客户端可以获取锁。
  • 只实现了独占锁。

没有羊群效应的锁实现

顺序临时节点：Zookeeper 提供一个多层级的节点命名空间（节点称为 Znode），每个节点都用一个以斜杠（/）分隔的路径来表示，而且每个节点都有父节点（根节点除外），非常类似于文件系统。节点类型可以分为持久节点（PERSISTENT ）、临时节点（EPHEMERAL），每个节点还能被标记为有序性（SEQUENTIAL），一旦节点被标记为有序性，那么整个节点就具有顺序自增的特点。一般我们可以组合这几类节点来创建我们所需要的节点，例如，创建一个持久节点作为父节点，在父节点下面创建临时节点，并标记该临时节点为有序性。

Lock:

n = create(l + “/lock-”, EPHEMERAL|SEQUENTIAL)
C = getChildren(l, false)
if n is lowest znode in C, exit
p = znode in C ordered just before n
if exists(p, true) wait for watch event
goto 2

Unlock:

delete(n)

首先，我们需要建立一个父节点，节点类型为持久节点（PERSISTENT） ，每当需要访问共享资源时，就会在父节点下建立相应的顺序子节点，节点类型为临时节点（EPHEMERAL），且标记为有序性（SEQUENTIAL），并且以临时节点名称 + 父节点名称 + 顺序号组成特定的名字。在建立子节点后，对父节点下面的所有以临时节点名称 name 开头的子节点进行排序，判断刚刚建立的子节点顺序号是否是最小的节点，如果是最小节点，则获得锁。如果不是最小节点，则阻塞等待锁，并且获得该节点的上一顺序节点，为其注册监听事件，等待节点对应的操作获得锁。当调用完共享资源后，删除该节点，关闭 zk，进而可以触发监听事件，释放该锁。

一般我们还可以直接引用 Curator 框架来实现 Zookeeper 分布式锁，代码如下：

InterProcessMutex lock = new InterProcessMutex(client, lockPath);
if ( lock.acquire(maxWait, waitUnit) ) {
    try {
        // do some work inside of the critical section here
    } finally {
        lock.release();
    }
}

读/写锁

Write Lock:

n = create(l + “/write-”, EPHEMERAL|SEQUENTIAL)
C = getChildren(l, false)
if n is lowest znode in C, exit
p = znode in C ordered just before n
if exists(p, true) wait for event

Read Lock:

n = create(l + “/read-”, EPHEMERAL|SEQUENTIAL)
C = getChildren(l, false)
if no write znodes lower than n in C, exit
p = write znode in C ordered just before n
if exists(p, true) wait for event
goto 3

对比 Redis 锁

  • Redis AP，ZooKeeper CP
  • Redis 非公平，ZooKeeper 可以公平

参考