Redisson 组件 + 支付业务场景落地对照表

本文结合金融支付 / 交易系统场景，把 Redisson 各类组件、对应业务场景、用法要点、简易示例一并整理，可直接作为技术文档使用。

Redisson 组件 + 支付业务场景落地对照表

一、分布式锁系列（支付核心刚需）

1. 可重入锁 RLock

适用场景

1. 订单创建、支付单状态流转（防止重复下单、重复回调）

1. 账户余额扣减 / 充值、钱包资金变动

1. 商户结算、对账单生成

1. 嵌套调用场景（方法内部二次加锁，可重入避免死锁）

使用要点

• 锁 Key 设计：lock:pay:order:{订单号}、lock:wallet:{用户ID}

• 优先tryLock限时抢锁，避免无限阻塞

• 必须在finally执行unlock()

• 业务耗时不确定时，不指定leaseTime，启用看门狗续期

示例

2. 读写锁 RReadWriteLock

适用场景

1. 支付配置、费率规则、渠道路由配置（读多写少）

1. 商户基础信息、支付限额查询

1. 公共缓存数据：支付通道状态、银行接口可用状态

逻辑

• 读锁：共享，多线程可同时查询配置

• 写锁：排他，修改费率 / 路由时禁止读写，保证数据一致

3. 公平锁 RFairLock

适用场景

1. 高并发秒杀支付、限时活动下单支付

1. 同一商户高频出款、代付排队
   作用：按请求先后顺序获取锁，避免请求饥饿。

4. 多重锁 MultiLock / 红锁 RedLock

适用场景（金融高可用）

1. 一笔交易同时操作用户钱包 + 商户账户（多 Key 原子加锁）→ 用MultiLock

1. 核心账务、清分、资金调拨（零丢锁要求）→ 用RedLock（多独立 Redis 节点）
   场景特点：支付资金类强一致性要求，杜绝单点故障丢锁。

二、分布式同步器（并发控制）

1. 信号量 RSemaphore

适用场景

1. 支付渠道接口限流（限制单银行 / 第三方渠道最大并发调用数）

1. 批量代付、批量退款任务并发控制

1. 风控拦截：限制同一 IP / 账号短时间支付请求量

示例：单个支付渠道最大并发 20

2. 闭锁 RCountDownLatch

适用场景

1. 一笔订单拆分多笔子支付，所有子单处理完成后再汇总状态

1. 日终对账：多个对账节点全部执行完毕，再触发收尾归档

1. 批量退款任务：等待所有退款请求处理完成，返回汇总结果

三、分布式原子类（计数、序号、库存）

RAtomicLong / RAtomicInteger

适用场景

1. 支付流水号、对账批次号、每日交易序号（分布式自增 ID）

1. 每日交易笔数、交易金额统计（实时指标）

1. 活动支付补贴剩余名额、营销库存扣减
   优势：原子操作，跨实例无并发问题。

四、分布式集合 & 容器

1. RBucket 通用对象容器

适用场景

1. 全局支付开关、系统维护状态

1. 临时存储支付回调上下文、会话临时数据

1. 全局风控黑名单总开关

2. RMap / RMapCache（分布式 Map / 二级缓存）

适用场景

1. 支付路由表：商户 ID → 支付渠道映射

1. 商户费率、支付限额、风控规则缓存

1. 支付结果临时缓存：订单号 → 支付状态（做防重复回调）
   推荐：RMapCache支持 TTL，自动过期，适配临时状态数据。

3. RList

适用场景

1. 待复核退款单、人工审核支付单列表

1. 流水临时排队队列（简单有序列表）

4. RScoredSortedSet 有序集合

适用场景

1. 交易金额排行榜、商户交易量排名

1. 按时间排序的异常支付单、逾期订单

五、队列体系（异步解耦、延迟任务，支付高频）

1. 阻塞队列 RBlockingQueue

适用场景

1. 异步记账、异步流水落地

1. 支付成功后异步通知商户、推送消息

1. 异步生成对账文件、凭证文件
   特点：多生产者多消费者，队列空则阻塞，削峰填谷。

2. 延迟队列 RDelayedQueue（支付核心场景）

适用场景

1. 订单超时未支付自动关闭（经典：15/30 分钟关单）

1. 支付成功后延迟校验、延迟对账

1. 退款申请延迟处理、账单逾期提醒

1. 预授权支付到期自动撤销

流程

1. 业务侧把订单放入延迟队列，指定延迟时间

1. 到期自动转入目标阻塞队列

1. 消费端监听队列，执行关单 / 撤销逻辑

3. 优先级队列 RPriorityQueue

适用场景

1. 紧急退款、大客户优先出款

1. 风控高优拦截订单优先处理

六、限流 & 防重 & 风控组件

1. 分布式限流器 RRateLimiter（令牌桶）

适用场景

1. 接口全局限流：下单、支付、退款接口 QPS 控制

1. 单个商户 / 账号维度限流（防刷、防恶意请求）

1. 对外开放支付 API 流量管控

2. 布隆过滤器 RBloomFilter

适用场景

1. 支付请求防重复提交（拦截重复订单号、流水号）

1. 风控黑名单快速匹配（海量手机号、账号拦截）

1. 缓存穿透拦截：判断订单 / 用户是否存在，减少 DB 查询
   特点：内存占用极低，亿级数据也可高效判断。

七、发布订阅 RTopic

适用场景

1. 支付渠道状态变更广播（银行接口宕机 / 恢复，全服务感知）

1. 系统配置热更新（费率、路由、开关变更推送）

1. 全局事件通知：开始日终对账、停止对外支付

八、地理空间 RGeo（支付延伸场景）

适用场景

1. 线下门店支付、聚合支付 LBS 场景（附近商户、门店定位）

1. 基于地理位置的风控（异地支付拦截、区域交易统计）

支付场景组件选用速查表

补充支付落地最佳实践

1. 锁粒度：优先按「订单号 / 用户 ID」加锁，禁止全局大锁，避免性能瓶颈。

1. 延迟队列：支付超时关单优先使用RDelayedQueue，替代轮询查库，大幅降负载。

1. 防重组合：接口层RRateLimiter+ 布隆过滤器 + 分布式锁，三层防重复支付。

1. 资金类强约束：账户扣款、清分、调拨，优先 RedLock / MultiLock，提升可用性。

1. 异步解耦：所有非核心链路（通知、记账、日志）全部走队列，提升支付主链路响应速度。

附录：

Redisson 用于支付系统的分布式锁核心原理

基于Redis + Lua 脚本实现，主流用红锁（RedLock）、可重入锁、看门狗续期，解决单机 / 集群环境下多实例互斥问题。

一、前置：为什么不用原生 RedisSETNX裸写锁？

原生命令：

裸写存在四大致命问题：

1. 不可重入：同一线程再次加锁直接失败（递归 / 嵌套场景崩）

1. 锁超时误释放：业务没跑完，锁自动过期，别人抢到锁

1. 锁被别人误删：A 加的锁，B 执行DEL直接删掉

1. 主从同步失效：主节点挂了，从节点没同步到锁，集群丢锁

Redisson 全部解决了以上问题。

二、Redisson 基础可重入锁（单机 / 主从架构）

1. 锁数据结构（Hash）

key：锁名称（如lock:order）
field：线程唯一 ID + 线程名称（标识哪个线程持有）
value：重入次数（计数）

2. 加锁：Lua 脚本（原子执行，防并发）

Lua 保证多条命令一次性执行，中间不会被其他请求打断。
逻辑：

1. 锁不存在 → 新建 Hash，当前线程占有，设置默认过期时间（默认30s），返回加锁成功

1. 锁存在且是当前线程持有→ 重入次数 +1，返回成功

1. 锁存在且不是当前线程→ 返回失败，抢锁阻塞

3. 可重入实现

同一线程多次lock()，只累加计数，不会死锁；
每次unlock()计数 -1，计数归 0 才真正删除锁。

4. 看门狗（Watch Dog）锁续期 —— 解决「业务超时锁自动释放」

这是 Redisson 最核心设计：

• 锁默认过期时间：30 秒

• 加锁成功后，后台启动定时任务（看门狗）

• 每10 秒（30s/3）检查一次：

• 如果当前线程还持有锁 →重置锁过期时间为 30s

• 业务正常运行 → 锁永远不会因为超时释放

• 业务执行完毕、主动解锁 → 看门狗停止

5. 解锁：Lua 脚本（防误删）

逻辑（原子执行）：

1. 判断锁是否存在、是否当前线程持有

1. 不是自己的锁 → 直接返回，禁止删除（解决误删问题）

1. 是自己的锁 → 重入次数 -1

1. 次数 > 0：只减计数，不删锁

1. 次数 = 0：删除整个锁 Key，同时停止看门狗

三、等待与阻塞机制（抢锁失败怎么办）

1. 抢锁失败的线程，不会无限轮询（低效）

1. Redisson 用Redis 发布 / 订阅（Pub/Sub）：

• 锁释放时，主动发布消息

• 等待中的线程收到通知，再重新尝试抢锁

1. 支持tryLock(等待时间)：超时抢不到直接返回 false，避免死等

四、Redisson 红锁 RedLock（Redis 集群 / 多节点防单点故障）

适用场景

Redis主从 + 哨兵仍有丢锁风险（主宕机、从未同步锁），多节点独立 Redis 部署用红锁。

原理（N 个独立 Redis 节点，一般 5 个）

1. 客户端依次向所有节点申请加锁

1. 成功加锁节点数 > 半数（多数派），才算整体加锁成功

1. 所有节点锁都设置较短超时，防止单节点卡死

1. 解锁：向所有节点统一执行解锁脚本

特点：

• 容忍少数节点宕机，强一致性

• 性能比单机锁略低，金融、支付等高可靠场景首选

五、整体流程极简梳理（单节点可重入锁）

1. 线程调用lock()

1. 执行 Lua：判断锁状态 → 占有 / 重入 / 等待

1. 加锁成功 → 启动看门狗定时续期

1. 业务代码执行（可嵌套重入）

1. 执行完毕调用unlock()

1. Lua 减计数 → 计数为 0 删除锁、关闭看门狗

1. 发布解锁消息，唤醒阻塞线程

六、核心亮点总结（对应原生 SETNX 缺陷）

1. ✅可重入：Hash + 计数，同一线程递归加锁没问题

1. ✅防误删：解锁校验线程 ID，别人删不掉你的锁

1. ✅锁自动续期：看门狗，业务多久锁持多久

1. ✅原子性：全靠 Lua 脚本保证

1. ✅优雅阻塞：Pub/Sub 通知，不是死循环轮询

1. ✅高可用：RedLock 多节点多数派，防单点故障

七、常用使用要点（实战）

• 默认锁有效期：30s，看门狗 10s 续一次

• lock()：阻塞抢锁；tryLock()：非阻塞 / 限时抢锁

• 必须finally 里 unlock，防止异常死锁

• 多服务、多机房、高可靠场景 → 用RedLock