# Redis 锁的超时

**URL:** <https://meta.discourse.org/t/timeouts-of-redis-lock/201520>\
**Category:** Development\
**Created:** [2021年八月24日 08:51 UTC](https://meta.discourse.org/t/timeouts-of-redis-lock/201520 "2021-08-24T08:51:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![concerto](https://avatars.discourse-cdn.com/v4/letter/c/dec6dc/32.png) [@concerto](https://meta.discourse.org/u/concerto)\
**Post date:** [2021年八月24日 08:51 UTC](https://meta.discourse.org/t/timeouts-of-redis-lock/201520/1 "2021-08-24T08:51:44Z")

</div>

Discourse 使用了 [DistributedMutex](https://github.com/discourse/discourse/blob/main/lib/distributed_mutex.rb)，这是一种针对多种场景的 Redis 锁实现。该 Redis 锁实现似乎包含超时机制，因此它更像是一种“租约”而非传统意义上的“锁”。

这可能会引发一些问题，例如：当 Redis 锁超时，但受该锁保护的工作尚未完成时，可能会出现竞态条件。

---

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [2021年八月24日 12:20 UTC](https://meta.discourse.org/t/timeouts-of-redis-lock/201520/2 "2021-08-24T12:20:32Z")

</div>

确实如此，但我们设计时会尽量让操作耗时远小于锁的超时时间。

如果完全没有任何超时机制，就可能出现互斥锁被永久占用的情况（例如：某个应用进程在持有锁时与 Redis 的连接中断）。