1. 支付幂等与数据唯一性
核心案例：三方支付回调/客户端重试导致的重复发货风险。
- 创建订单按
accountId加 Redis 分布式锁，避免同一用户并发创建重复订单。 - 验单按
orderNum加锁，并在支付成功前检查订单终态，已完成则拒绝重复支付。 - Google 支付还利用渠道侧状态做幂等：订阅检查
acknowledgementState，一次性商品检查consumptionState，重复验单直接返回。 - 续订通知以
latestOrderId查重，避免同一个续订事件重复创建订单和重复延长会员。
可以这样讲：
在支付场景中，客户端重试、支付平台回调重投、服务多实例并发都会造成同一笔交易被重复处理。我们按资源粒度设计了两层幂等：创建阶段按用户加分布式锁，验单阶段按订单号加锁；业务层再以订单支付状态作为最终拦截，并结合 Google 的消费/确认状态识别重复请求。对于续订通知，以第三方的
latestOrderId作为事件标识查重。目标是保证会员发放、金币到账等副作用至多执行一次。
Redis 锁只是并发控制，不是最终数据约束。更稳妥的演进方案是在订单/支付流水表上为第三方交易号或幂等键建立唯一索引，并捕获唯一键冲突后查询并返回已有结果，形成“分布式锁 + 状态机 + 数据库唯一约束”的三道防线。
2. Redisson在项目中应用
运营分配模块用 Redisson 统一 Redis 访问。针对不同问题选不同数据结构：
-
Map 存用户归属，
-
ZSet 做公平调度与超时扫描，
-
BlockingQueue 做轮询分配，左进右出，
-
DelayedQueue 做延迟提醒和自动释放， 超时承接，Redis 延迟队列实现
-
RLock 保证同一用户建联的幂等和互斥。颗粒度为 accountId 用户id
设计时重点关注原子性、缓存一致性、任务幂等、锁租约和 Redis key 的生命周期