当前位置：首页 > news >正文

Redis的watch机制详解

news 来源：原创 2024/9/20 4:39:10

WATCH 是 Redis 提供的一个用于实现 乐观锁 (Optimistic Lock) 的命令，通常用于实现事务中的并发控制。它允许客户端监控一个或多个键的变化，并确保事务（MULTI/EXEC）中执行的操作在这些键没有发生改变的情况下才能成功提交。若在事务执行前，某些键被其他客户端修改，事务将被中止，避免潜在的并发修改问题。

WATCH 的工作机制

监听键
- 客户端通过 WATCH 命令可以监听一个或多个键。执行后，Redis 会将这些键标记为被当前客户端监视的状态。
- 一旦这些被监视的键在 EXEC 之前被其他客户端修改（包括 DEL, SET, INCR, DECR 等操作），事务就会被中止。
事务的执行
- 在监听键后，客户端会开始一个事务块，使用 MULTI 命令，表示事务的开始。
- 然后客户端可以执行一系列 Redis 命令，但这些命令不会立即执行，而是放入事务队列。
- 最终，客户端使用 EXEC 命令提交事务，Redis 将检查被 WATCH 的键在事务执行前是否被修改过。如果没有变化，所有命令将被原子性地执行；如果有任何一个被监视的键被修改，事务会中止，返回 nil，表示事务失败。
取消监视
- 可以通过 UNWATCH 命令手动取消监视键。
- 当 EXEC 命令执行后，所有 WATCH 监视的键也会被自动取消。
- 如果客户端在 MULTI/EXEC 事务块中使用了 DISCARD 命令，事务会被取消，且 WATCH 的效果也会失效。

使用 `WATCH` 的例子

# Client A
WATCH mykey
MULTI
INCR mykey
EXEC

假设此时 Client A 在监听 mykey，并准备执行事务。如果 mykey 被 Client B 修改：

# Client B
SET mykey 100

然后 Client A 执行 EXEC，由于 mykey 在 EXEC 之前已经被 Client B 修改，事务会失败，返回 nil。

乐观锁的机制

WATCH 的核心思想是乐观锁机制。与悲观锁不同，乐观锁假设并发操作很少发生，并在操作前先不锁定资源，而是允许多个客户端对数据进行操作和修改。在提交前，通过 WATCH 确保没有其他客户端对数据进行了修改，如果检测到冲突，操作会回滚或者重新尝试。

这种机制特别适用于以下场景：

需要在高并发下处理数据的场景。
希望通过简洁的方式控制并发修改。
对于不确定的并发情况，可以避免频繁加锁的复杂性。

WATCH 与 MULTI/EXEC 的关系

MULTI/EXEC 实现的是原子性事务，但没有自动的并发控制机制。
WATCH 可以与 MULTI/EXEC 配合，增加对并发修改的检测，确保事务提交时数据不会发生意外变化。

WATCH 的注意事项

只监视变化，而不是加锁：WATCH 仅仅是监视键是否发生了变化，不会阻止其他客户端对该键的修改。也就是说，WATCH 并不会提供类似于悲观锁的资源保护，只是用来检测冲突。
长时间监视代价大：长时间使用 WATCH 会增加 Redis 的监视列表大小，并消耗内存资源。因此，监视应该尽量在事务短时间内执行完毕，避免 WATCH 的持久存在。
取消监视：如果 EXEC 失败，事务被中止，或者客户端主动取消了监视（使用 UNWATCH），应该注意重新开始一个新的 WATCH 周期。

典型应用场景

乐观锁：在数据操作时确保事务中的键没有被其他客户端修改，以避免数据冲突。
计数器：例如，对一个计数器的原子性递增操作，确保在高并发下，多个客户端不会发生数据覆盖或丢失问题。
库存管理：在电子商务系统中，检查和更新商品库存可以通过 WATCH 来确保库存不会被多个客户端同时操作，从而避免超卖问题。

WATCH 的性能与局限性

性能：WATCH 的开销与 Redis 的高性能特性结合得很好，它依赖于 Redis 的内存存储和事件驱动模型，能以低开销监视大量的键。
局限性：WATCH 是乐观锁的一种形式，对于高并发环境下的冲突，可能需要多个客户端进行重试，这在非常高的并发场景中可能会带来一定的延迟。此外，如果一个事务的执行逻辑复杂，WATCH可能导致频繁的失败重试。