在分布式微服务架构中，因网络抖动、客户端超时重试、前端弱网环境下的连击，以及 MQ 消息重复推送等原因，同一业务请求多次到达服务端是不可避免的常态。若接口缺乏幂等保护，极易引发资金重复扣减、库存超卖、数据脏读等严重生产事故。

本文聚焦高并发场景，系统梳理基于 Redis 构建幂等屏障的核心方案，并剖析分布式环境下易忽视的边界陷阱与应对策略。

一、 幂等设计的两层防护体系
实现接口幂等，核心逻辑是通过唯一标识拦截后续到达的重复请求。在工程实践中，通常结合以下两种机制：

1. 客户端 Token 机制（防前端连击/重试）
   流程：客户端进入表单或支付页面前，向服务端申请一个全局唯一的请求 Token（如 UUID + 请求签名）；

校验：提交业务请求时携带该 Token。服务端通过原子操作验证并消费该 Token，仅放行首次提交，后续相同 Token 请求直接阻断。

适用场景：用户端主动发起的增删改表单提交、支付结算确认等交互型操作。

2. 业务指纹/唯一流水号机制（防服务间重试与 MQ 重复消费）
   流程：利用强业务属性字段（例如 UserId + BizType + OrderId）或针对核心 Payload 参数生成摘要作为业务指纹；

校验：在执行业务代码前，在 Redis 中以指纹作为 Key 进行原子占位。

适用场景：开放平台 API、内部 RPC 接口重试、MQ 消费监听。

二、 核心实现方案与代码范式
在 Redis 中实现互斥锁定与防重，必须保证加锁占位与解锁释放的绝对原子性，防止因网络中断、进程异常退出引发死锁，或在锁超时后误删他人持有的锁。

1. 原子加锁与 TTL 设定
   必须使用单一原子指令 SET key value NX PX，杜绝将 SETNX 与 EXPIRE 拆开执行：

Python
import uuid
import redis

初始化 Redis 客户端连接

client = redis.StrictRedis(host=“127.0.0.1”, port=6379, db=0, decode_responses=True)

def try_acquire_idempotent_lock(biz_key: str, expire_ms: int = 5000) -> str | None:
“”"
尝试获取幂等占位锁
:param biz_key: 业务唯一标识（如 order_id 或 防重 token）
:param expire_ms: 兜底失效时间（毫秒），防止业务宕机死锁
:return: 成功返回生成的 request_token，失败返回 None
“”"
lock_key = f"idempotent:{biz_key}"
request_token = str(uuid.uuid4())

# NX: 键不存在时才设置成功; PX: 过期时间单位为毫秒
is_success = client.set(lock_key, request_token, nx=True, px=expire_ms)
return request_token if is_success else None

2. 基于 Lua 脚本的安全解锁
   释放锁时不可直接执行 DEL。若接口处理时间超出预设 TTL，锁已自动过期被其他并发线程获取，直接 DEL 会导致误删其他线程的锁。必须通过 Lua 脚本原子性校验 Token 匹配后再行删除：

Python

安全释放锁的 Lua 脚本

LUA_UNLOCK_SCRIPT = “”"
if redis.call(“get”, KEYS[1]) == ARGV[1] then
return redis.call(“del”, KEYS[1])
else
return 0
end
“”"

def release_idempotent_lock(biz_key: str, request_token: str) -> bool:
“”"
安全释放幂等锁
:param biz_key: 业务唯一标识
:param request_token: 加锁时返回的唯一值
:return: 是否释放成功
“”"
lock_key = f"idempotent:{biz_key}"
result = client.eval(LUA_UNLOCK_SCRIPT, 1, lock_key, request_token)
return result == 1
三、 生产环境常见踩坑与边界防御

1. 业务耗时超出 TTL 导致锁穿透
   隐患分析：当下游微服务出现慢调用或数据库发生锁等待时，处理耗时可能超出预设的 5 秒。Redis 侧 Key 自动失效，后续重试请求成功获取锁进入业务层，造成重复插入或更新。

规避策略：

缩小加锁粒度：分布式锁仅用于锁定核心状态判断与入库事务，禁止将外部耗时 HTTP 交互、文件上传等非强原子操作包裹在锁区间内。

看门狗续期机制（Watchdog）：对耗时波动较大的关键链路，在锁获取成功后开启守护线程/异步任务，每隔一段固定周期（如 TTL 的 1/3）检查任务执行状态并原子性重置 TTL，任务结束后显式终止续期。

2. 锁释放与本地数据库事务的时序错位
   隐患分析：在常见的 AOP 切面实现中，若开发者将解锁切面置于 @Transactional 内，或在本地事务提交前触发了解锁：

线程 A 获取锁 -> 业务逻辑执行完成 -> 释放锁 -> 本地事务 Commit 阶段（网络或 IO 阻塞）
线程 B 获取锁 -> 查询数据库（此时线程 A 尚未提交，查到旧数据） -> 重复执行插入 -> 线程 A 提交
规避策略：

分布式锁必须在外层环绕切面中执行，必须在本地事务完全提交（Commit）成功后，才允许执行释放逻辑。

对于强一致业务，在底层的数据库表上对核心唯一键（如订单号、外部流水号）添加唯一索引（UNIQUE INDEX）作为最终防御底线。

3. 主从切换导致的分裂锁（脑裂与同步延迟）
   隐患分析：在 Redis Sentinel 或 Cluster 架构中，主节点写入成功但尚未同步到从节点时，主节点发生宕机。从节点被提升为主节点后，新主节点缺少该锁键，导致另一个请求再次获取成功。

规避策略：

大多数业务场景中，主从毫秒级同步延迟引发冲突的概率极低，搭配数据库唯一索引即可覆盖 99.99% 的异常。

针对金融级结算等极端场景，可采用 Redlock 算法在多个互不相干的独立 Redis 实例上进行多点仲裁，确保跨节点多数派写入确认后再放行业务。