北京
支付网关的集成向来不留情面。外部支付接口调用过程中一旦出现网络超时，客户端应用往往无法判断这笔交易究竟是成功了、失败了，还是仍在处理中。盲目重试可能造成重复扣款，直接放弃又会留下废弃的订单和流失的收入。
现代支付平台给出的解法是幂等键（Idempotency Key）配合分布式锁。下面这套实现基于 Python、Pydantic、Redis 与原子 Lua 脚本，重点在于并发控制，以及生产环境里必须提前设计的边界情况与架构取舍。
架构目标与核心决策
这套架构的核心目标只有一个：为每个唯一的客户端请求保证单次执行权，同时对并发重复请求做拒绝或安全重放。
请求进入后的处理顺序是：先查数据库是否已有已完成的交易记录，命中则直接返回幂等重放结果；未命中则尝试在 Redis 上加锁，抢锁失败返回冲突或锁定状态；抢锁成功后再做一次数据库复查，然后才调用外部支付网关，落库并释放锁。
三个关键设计点：
- 请求指纹唯一化：客户端必须为每一次交易意图生成一个 RFC-4122 UUID v4。如果网络延迟触发了自动重试，客户端要重复使用完全相同的键。
- Redis 原子抢锁：用 SET lock_key token PX 5000 NX 建立带 5000 毫秒存活期的互斥锁。NX 保证只有第一个调用方能拿到锁，PX 保证处理节点崩溃时锁会自动过期，避免永久死锁。
- Lua 脚本安全释放：直接执行 DEL 命令，在当前操作超过 TTL 时可能误删别的进程持有的锁。在原子 Lua 脚本里先校验执行令牌再删除键，才能保证一个线程只释放自己持有的锁。
验证脚本的工程细节
示例脚本做了几处务实的处理。序列化层优先使用 orjson，导入失败时回退到标准 json，兼顾性能与可移植性。请求体用 Pydantic v2 做严格校验，金额字段限定为正整数，校验失败直接返回 ERROR 状态而不是让脏数据进入流程。
流程里有两处容易被忽略的复查。第一处是抢锁前的数据库短路查询，已完成的请求不必再碰锁。第二处是抢锁成功后的二次查询，用来堵住锁交接窗口内的竞态。脚本随后模拟外部支付网关的调用，再把交易记录写入主存储，最后在 finally 块里通过 Lua 脚本释放锁；释放过程即使抛异常也被吞掉，退化为依赖键的 TTL 自然过期。
主程序模拟了两个请求：第一个携带新生成的键，返回成功和交易号；第二个用完全相同的键重试，直接命中幂等重放，返回同一条交易记录。
生产环境的三个硬伤
这套实现能解决本地竞态，放到规模化部署里就会撞上分布式系统的老问题。
一是 Redis 主从异步复制带来的脑裂。主节点刚授予锁、还没来得及把这次写入同步到从节点就宕机，新晋升的从节点上根本没有这把锁的记录。第二个客户端于是能拿到锁，而第一个请求还在处理中。关键资金链路要么用 Redlock 算法跨多个独立 Redis 实例，要么用关系型数据库的悲观锁（SELECT ... FOR UPDATE）和库级唯一约束给 Redis 锁兜底。
二是 TTL 与下游延迟的取舍。外部支付处理器如果卡住 7 秒，而锁的 TTL 只有 5000 毫秒，锁会提前过期，并发重试就能拿到锁并再发一次支付调用，此时原请求仍在飞行中。反过来把 TTL 设得过高，工作进程突然终止时锁的占用时间又会被拉长。可行的做法是加一个后台心跳线程或异步看门狗，在任务执行期间周期性续期，任务完成或异常退出时停止续期。
三是 Redis 与关系库之间的状态同步开销。Redis 里的分布式锁只是应用层的吞吐优化器，用来在并发压力下挡掉不必要的接口调用；真正的真相来源始终是数据库对幂等键的唯一约束。双状态管理意味着应用服务器、Redis 与主关系库之间的网络分区会带来短暂不一致，需要补偿事务或死信队列来收尾。
纵深防御
支付幂等不可能靠单一中间件解决。边缘或网关层用快速分布式锁做请求去重，工作层为长耗时 I/O 做动态心跳续期，数据库层对幂等键施加唯一约束，保证缓存失效时数据完整性依然成立。三层各管一段，缺一层都会在某个故障场景下漏出重复扣款的口子。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
