Redis 竞争条件

返回术语表

理解竞争条件

竞争条件出现在系统行为不可预测地依赖事件顺序时，例如各个线程执行的顺序。在 Redis 中，当多个客户端同时访问或修改相同的数据时，可能会发生这种情况，从而导致不可预见的成果。

Redis 的单线程性质

Redis 以单线程方式运行，顺序处理命令。虽然这确保了各个命令的原子性，但在多个客户端同时与 Redis 交互时，仍会出现竞争条件。

信号量操作中的竞争条件

信号量是一种用于控制访问资源的机制。在 Redis 中，当多个进程（例如 A 和 B）争用一个信号量时，可能会出现竞争条件。例如，如果 A 在 B 之前更新计数器但 B 先检查了其在 ZSET 中的排名，则 B 可能错误地获取了信号量。然后，当 A 检查其排名时，它可能会无意间从 B “抢走”信号量，当 B 尝试更新或释放该信号量时会导致混乱。

以前，使用系统时钟来管理锁使得这些竞争条件更容易发生，尤其是当系统时间有显著不同的时候。通过结合所有者 ZSET 引入计数器，降低了这种风险。但是，由于涉及到多个步骤，因此竞争条件仍然有可能发生。

使用锁解决竞争条件

要全面解决这些竞争条件，可以使用带超时的分布式锁。这涉及到首先尝试为信号量获取锁。如果成功，则执行标准信号量操作。如果失败，则信号量获取被视为不成功。以下是一个简化的函数版本

def acquire_semaphore_with_lock(conn, semname, limit, timeout=10)

   identifier = acquire_lock(conn, semname, acquire_timeout=.01)

   if identifier

      try

         return acquire_fair_semaphore(conn, semname, limit, timeout)

      finally

         release_lock(conn, semname, identifier)

在取得所有这些进展后求助于锁似乎有违直觉，但对于类似问题，Redis 提供了多种解决方案，每个解决方案都有其优缺点。视所需严格性而定。

1. 对于使用系统时钟、不需要信号量刷新且容忍偶尔违反限制的人来说，最初的信号量方法就足够了。
2. 如果系统时钟仅在 1-2 秒范围内被信任，但偶尔违反限制是可以接受的，则第二种方法是合适的。
3. 为了每次都能保证正确性，使用锁是最佳方法。

虽然最后一种方法最准确，但使用更简单的信号量节省的时间可能会因资源过度使用而被抵消。

信号量的应用

Redis 中的信号量可以用来调节同时进行的 API 调用次数，确保数据库不会因并发请求而不堪重负。它们还可以用来遵守限制（例如网站 robots.txt 中施加的限制），确保服务器不会过载。