面向高并发生产场景的 Redis 事务四步关键操作详解

一、WATCH 观察：高并发生产场景中的前置条件与乐观锁机制

在高并发场景下，数据竞争往往来自多客户端对同一键的并发读写。WATCH提供了一种乐观锁机制，用来在提交事务前对关键键进行监视，从而避免脏写和更新丢失的风险。

通过观察阶段，应用可以判断在事务提交前数据是否被其他并发操作修改。如果被修改，事务将被中止，从而促使应用进行重试或回退，确保最终的数据一致性。此处的核心思想是

使用

WATCH key1 key2

的方式对多个关键键进行监视，并在后续执行阶段决定是否提交。若监视键发生变化，客户端应立即取消观察并采取相应的回退策略。下面给出一个简洁的监视示例，便于理解其对高并发的保护作用：

WATCH product:stock:123
GET product:stock:123
MULTI
DECRBY product:stock:123 1
EXEC

在实际生产中，幂等性与幂等性保护同样重要。通过为每次请求附带全局唯一标识（如事务ID），可以在出现冲突时实现幂等输出，避免重复执行导致的副作用。

关键要点回顾

在这个阶段，数据一致性、乐观锁、以及对并发争抢资源的可控性是核心关键点。通过WATCH，系统能在提交前对关键字段进行快照检查，确保后续操作只在数据未被修改的前提下才持续。

二、MULTI 启动事务：命令排队与原子性边界

MULTI开启事务后，后续的所有命令会被排队，直到遇到EXEC才执行。这就建立了一个原子性边界：要么全部执行成功，要么全部不执行，避免了中间状态对外暴露。

在高并发场景中，队列化执行可以降低跨请求的竞争冲突，但也需要慎重设计命令顺序，确保幂等性与一致性。若在事务开启后，有效条件发生变化，应用应在执行阶段前评估并决定是否继续提交。

以下示例展示了如何在应用代码中，使用

language-python

来实现带监视的事务启动与命令排队。通过这种方式，启动事务、排队命令、与后续执行的边界清晰可控：

import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)def reserve_stock(product_id, amount):with r.pipeline() as pipe:while True:try:pipe.watch(product_id)stock = int(pipe.get(product_id) or 0)if stock < amount:pipe.unwatch()return False  # 库存不足，回退pipe.multi()  # 开启事务pipe.decrby(product_id, amount)pipe.execute()  # 交给EXEC原子执行return Trueexcept redis.WatchError:# 监视的键在执行前被修改，重试continue
''

在高并发环境下，这类实现的关键是保持幂等性设计和对异常的鲁棒处理，以避免重复扣减或错误状态的持续积累。

三、EXEC 提交：原子性执行与返回结果解读

EXEC命令将把排队的所有命令原子地执行，并返回一个结果集合。若在执行前监视的键被其他客户端修改，EXEC将返回空值（nil），表示提交失败，需要通过重试策略来处理。

正确理解EXEC 的返回机制是确保高并发场景中正确处理冲突的关键。通过返回的结果可以判断哪些操作执行成功，哪些因为并发冲突被放弃，从而实现精准的幂等性与补偿逻辑。

以下给出一个结合

language-python

的撤销再提交示例，以及一个纯Redis CLI的提交流程，帮助你快速落地到生产代码中：

import redis
r = redis.Redis(...)
MAX_RETRIES = 3def purchase(product_id, amount):for _ in range(MAX_RETRIES):with r.pipeline() as pipe:try:pipe.watch(product_id)stock = int(pipe.get(product_id) or 0)if stock < amount:pipe.unwatch()return Falsepipe.multi()pipe.decrby(product_id, amount)result = pipe.execute()if result is not None:return True  # 成功执行# 如果为空，则代表并发冲突，重试except redis.WatchError:continuereturn False

WATCH product:stock:123
GET product:stock:123
MULTI
DECRBY product:stock:123 1
EXEC

在生产环境中，事务结果解读、失败时的重试策略至关重要。对高并发写入，需要设计合适的退避时间、最大重试次数，以及记录冲突统计，确保系统长期稳定运行。

四、DISCARD/重试策略：失败情况下的幂等性与回退

DISCARD是事务在进入MULTI状态后若决定取消提交所用的命令清单的清空操作。与之相对，UNWATCH用于取消WATCH监视，使未执行的事务回到未监视状态，避免不必要的资源浪费。

在高并发场景，失败后的重试策略需要具备幂等性保障：使用唯一的事务标识、确保重复执行不会产生副作用、并结合指数退避降低冲突概率。对于不可避免的冲突，合理的回退方案能有效提升系统吞吐量与稳定性。

下面的代码展示了一个带回退的重试模板，以及在需要时如何显式DISCARD以清空未提交的事务：

import time, random
MAX_RETRIES = 5def exec_with_backoff(product_id, amount):for attempt in range(1, MAX_RETRIES + 1):try:with r.pipeline() as pipe:pipe.watch(product_id)stock = int(pipe.get(product_id) or 0)if stock < amount:pipe.unwatch()return Falsepipe.multi()pipe.decrby(product_id, amount)pipe.execute()return Trueexcept redis.WatchError:# 回退并进行指数退避sleep = min(0.1 * (2 ** attempt), 1.0)time.sleep(sleep + random.random() * 0.05)continuereturn False# 直接 DISCAR D 用于取消未提交的事务（示例）
# DISCARD

综合来看，DISCARD/UNWATCH提供了明确的回退路径，确保在高并发环境中，未完成的事务不会污染后续的执行序列。