Redis distributed lock - 版本历史

2025年5月28日 (三) 07:58 Riguz

2025-05-28T07:58:25Z

←上一版本		2025年5月28日 (三) 07:58的版本
第53行：		第53行：
	# If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to <span class="article-label">unlock all the instances</span> (even the instances it believed it was not able to lock).		# If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to <span class="article-label">unlock all the instances</span> (even the instances it believed it was not able to lock).

			= Is redlock safe? =
			* https://juejin.cn/post/6976538149904678925

	* [https://redis.io/topics/distlock Distributed locks with Redis]		* [https://redis.io/topics/distlock Distributed locks with Redis]

Riguz：Riguz移动页面Blog:Redis实现分布式锁至Redis distributed lock，不留重定向

2023-12-19T05:46:07Z

Riguz移动页面Blog:Redis实现分布式锁至Redis distributed lock，不留重定向

←上一版本	2023年12月19日 (二) 05:46的版本
（没有差异）

Riguz：/* Redlock 算法 */

2021-06-28T13:21:44Z

Redlock 算法

←上一版本		2021年6月28日 (一) 13:21的版本
第60行：		第60行：
	[[Category:Distributed]]		[[Category:Distributed]]
	[[Category:Database]]		[[Category:Database]]
			[[Category:Redis]]

Riguz：/* Redlock 算法 */

2021-05-06T08:07:08Z

Redlock 算法

←上一版本		2021年5月6日 (四) 08:07的版本
第49行：		第49行：
	# It gets the current time in milliseconds.		# It gets the current time in milliseconds.
	# It tries to acquire the lock in all the <span class="article-label">N</span> instances <span class="article-label">sequentially</span>, using the <span class="article-label">same key name and random value</span> in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.		# It tries to acquire the lock in all the <span class="article-label">N</span> instances <span class="article-label">sequentially</span>, using the <span class="article-label">same key name and random value</span> in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.
	# The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.		# The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the <span class="article-label">majority</span> of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
	# If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3.		# If the lock was acquired, its validity time is considered to be the initial validity time <span class="article-label">minus the time elapsed</span>, as computed in step 3.
	# If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).		# If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to <span class="article-label">unlock all the instances</span> (even the instances it believed it was not able to lock).

Riguz：/* Redlock 算法 */

2021-05-06T08:06:30Z

Redlock 算法

←上一版本		2021年5月6日 (四) 08:06的版本
第46行：		第46行：

	= Redlock 算法=		= Redlock 算法=
	(~~TBD~~)		In a redis cluster with N master nodes, eg N=5, In order to acquire the lock, the client performs the following operations:
			# It gets the current time in milliseconds.
			# It tries to acquire the lock in all the <span class="article-label">N</span> instances <span class="article-label">sequentially</span>, using the <span class="article-label">same key name and random value</span> in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.
			# The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
			# If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3.
			# If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).

Riguz：/* redis单机下的正确做法 */

2021-05-06T05:23:00Z

redis单机下的正确做法

←上一版本		2021年5月6日 (四) 05:23的版本
第28行：		第28行：
	SET resource_name my_random_value NX PX 30000		SET resource_name my_random_value NX PX 30000
	</syntaxhighlight>		</syntaxhighlight>
	其中，<span class="article-label">NX</span>~~保证只有在key不存在的情况下才会被设置到redis中，~~<span class="article-label">PX 30000</span> 设置了过期时间为30000毫秒。而key的值被设置为一个随机值，这个值必须在所有的客户端和加锁请求中唯一。之所以要这么做，是为了保证能够安全的释放锁，只有当key存在，且是由锁的持有者发起的解锁请求的时候，才删除这个key：		其中，
			* <span class="article-label">NX</span>保证只有在key不存在的情况下才会被设置到redis中（防止竞争）
			* <span class="article-label">PX 30000</span> 设置了过期时间为30000毫秒
			* key的值被设置为一个随机值，这个值必须在所有的客户端和加锁请求中唯一。之所以要这么做，是为了保证能够安全的释放锁，只有当key存在，且是由锁的持有者发起的解锁请求的时候，才删除这个key：

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">

2021年5月2日 (日) 14:56 Riguz

2021-05-02T14:56:26Z

←上一版本		2021年5月2日 (日) 14:56的版本
第1行：		第1行：
	~~Redis一个比较重要的应用场景就是分布式锁DLM~~ (Distributed Lock Manager)。实际上已经有很多现成的redis库来完成这个功能了，但是可能实现途径有所差别，那么，正确的做法是什么呢？Redis官方建议了一个算法叫做`Redlock`，可以将其作为起点去实现更复杂的方案，来研究一下它的思路。		Redis一个比较重要的应用场景就是分布式锁<span class="article-label">DLM (Distributed Lock Manager)</span>。实际上已经有很多现成的redis库来完成这个功能了，但是可能实现途径有所差别，那么，正确的做法是什么呢？Redis官方建议了一个算法叫做<span class="article-label">Redlock</span>，可以将其作为起点去实现更复杂的方案，来研究一下它的思路。


第28行：		第28行：
	SET resource_name my_random_value NX PX 30000		SET resource_name my_random_value NX PX 30000
	</syntaxhighlight>		</syntaxhighlight>
	其中，`NX`保证只有在key不存在的情况下才会被设置到redis中，`PX 30000` 设置了过期时间为30000毫秒。而key的值被设置为一个随机值，这个值必须在所有的客户端和加锁请求中唯一。之所以要这么做，是为了保证能够安全的释放锁，只有当key存在，且是由锁的持有者发起的解锁请求的时候，才删除这个key：		其中，<span class="article-label">NX</span>保证只有在key不存在的情况下才会被设置到redis中，<span class="article-label">PX 30000</span> 设置了过期时间为30000毫秒。而key的值被设置为一个随机值，这个值必须在所有的客户端和加锁请求中唯一。之所以要这么做，是为了保证能够安全的释放锁，只有当key存在，且是由锁的持有者发起的解锁请求的时候，才删除这个key：

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
第47行：		第47行：

	* [https://redis.io/topics/distlock Distributed locks with Redis]		* [https://redis.io/topics/distlock Distributed locks with Redis]

			[[Category:Distributed]]
			[[Category:Database]]

imported>Riguz：Redis一个比较重要的应用场景就是分布式锁DLM (Distributed Lock Manager)。实际上已经有很多现成的redis库来完成这个功能了，但是可能实现途径有所差别，那么，正确的做法是什么呢？Redis官方建议了一个算法叫做`Redlock`，可以将其作为起点去实现更复杂的方案，来研究一下它的思路。

2020-07-17T00:00:00Z

新页面

Redis一个比较重要的应用场景就是分布式锁DLM (Distributed Lock Manager)。实际上已经有很多现成的redis库来完成这个功能了，但是可能实现途径有所差别，那么，正确的做法是什么呢？Redis官方建议了一个算法叫做`Redlock`，可以将其作为起点去实现更复杂的方案，来研究一下它的思路。

= 原则=

要实现分布式锁得满足一些必要的条件：

* 互斥性：任意时刻只能有一个客户端能够成功获取锁
* 避免死锁：即使锁的持有者crash
* 容错性：只要redis集群大多数节点正常，客户端就能够获取或者释放锁

有一些常见的做法并不是安全的锁实现方式。

最简单的做法是，获取锁时，在redis创建一个带有过期时间的key。当需要释放锁时，删除这个key。这种做法无法避免单点故障，如果redis master宕机，则无法成功获取或者释放锁了。如果添加一个slave节点呢？很不幸也行不通，因为redis的主从复制是异步的，由此带来竞争：

* Client A 在master节点上获取了锁
* master节点在将数据同步到slave之前crash掉了
* slave提升为新的master
* Client B于是可以获取到相同的锁了（不满足互斥性）

= redis单机下的正确做法=

在不考虑redis集群的情况下，如何正确的实现一个分布式锁呢？其实也比较简单：

加锁：

<syntaxhighlight lang="bash">
SET resource_name my_random_value NX PX 30000
</syntaxhighlight>
其中，`NX`保证只有在key不存在的情况下才会被设置到redis中，`PX 30000` 设置了过期时间为30000毫秒。而key的值被设置为一个随机值，这个值必须在所有的客户端和加锁请求中唯一。之所以要这么做，是为了保证能够安全的释放锁，只有当key存在，且是由锁的持有者发起的解锁请求的时候，才删除这个key：

<syntaxhighlight lang="lua">
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
</syntaxhighlight>

主要避免的一个问题就是，锁被其他的客户端给错误地释放了（有可能客户端释放锁的时候，因为某些原因锁已经过期了，但是其他的客户端已经获得了锁）。而锁的过期时间（或者说有效期），应该足够client完成操作，避免任务在进行的过程中其他客户端又获得了锁。

在单机的情况下以上就实现了一个较为完美的锁，如果要扩展到redis集群呢？

= Redlock 算法=
(TBD)

* [https://redis.io/topics/distlock Distributed locks with Redis]

Redis distributed lock - 版本历史

2025年5月28日 (三) 07:58 Riguz

Riguz：​Riguz移动页面Blog:Redis实现分布式锁至Redis distributed lock，不留重定向

Riguz：​/* Redlock 算法 */

Riguz：​/* Redlock 算法 */

Riguz：​/* Redlock 算法 */

Riguz：​/* redis单机下的正确做法 */

2021年5月2日 (日) 14:56 Riguz

Riguz：Riguz移动页面Blog:Redis实现分布式锁至Redis distributed lock，不留重定向

Riguz：/* Redlock 算法 */

Riguz：/* Redlock 算法 */

Riguz：/* Redlock 算法 */

Riguz：/* redis单机下的正确做法 */