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

本文结合金融支付 / 交易系统场景把 Redisson 各类组件、对应业务场景、用法要点、简易示例一并整理可直接作为技术文档使用。Redisson 组件 支付业务场景落地对照表一、分布式锁系列支付核心刚需1. 可重入锁 RLock适用场景订单创建、支付单状态流转防止重复下单、重复回调账户余额扣减 / 充值、钱包资金变动商户结算、对账单生成嵌套调用场景方法内部二次加锁可重入避免死锁使用要点锁 Key 设计lock:pay:order:{订单号}、lock:wallet:{用户ID}优先tryLock限时抢锁避免无限阻塞必须在finally执行unlock()业务耗时不确定时不指定leaseTime启用看门狗续期示例javaRLock lock redissonClient.getLock(lock:pay:order: orderNo);try {// 等待5秒锁默认30秒看门狗续期boolean ok lock.tryLock(5, TimeUnit.SECONDS);if (!ok) {throw new BizException(订单处理中请稍后重试);}// 执行支付单校验、扣款、状态更新} finally {if (lock.isHeldByCurrentThread()) {lock.unlock();}}2. 读写锁 RReadWriteLock适用场景支付配置、费率规则、渠道路由配置读多写少商户基础信息、支付限额查询公共缓存数据支付通道状态、银行接口可用状态逻辑读锁共享多线程可同时查询配置写锁排他修改费率 / 路由时禁止读写保证数据一致3. 公平锁 RFairLock适用场景高并发秒杀支付、限时活动下单支付同一商户高频出款、代付排队作用按请求先后顺序获取锁避免请求饥饿。4. 多重锁 MultiLock / 红锁 RedLock适用场景金融高可用一笔交易同时操作用户钱包 商户账户多 Key 原子加锁→ 用MultiLock核心账务、清分、资金调拨零丢锁要求→ 用RedLock多独立 Redis 节点场景特点支付资金类强一致性要求杜绝单点故障丢锁。二、分布式同步器并发控制1. 信号量 RSemaphore适用场景支付渠道接口限流限制单银行 / 第三方渠道最大并发调用数批量代付、批量退款任务并发控制风控拦截限制同一 IP / 账号短时间支付请求量示例单个支付渠道最大并发 20javaRSemaphore semaphore redissonClient.getSemaphore(sem:channel:alipay);semaphore.tryAcquire(1, 3, TimeUnit.SECONDS);// 调用支付宝支付接口semaphore.release();2. 闭锁 RCountDownLatch适用场景一笔订单拆分多笔子支付所有子单处理完成后再汇总状态日终对账多个对账节点全部执行完毕再触发收尾归档批量退款任务等待所有退款请求处理完成返回汇总结果三、分布式原子类计数、序号、库存RAtomicLong / RAtomicInteger适用场景支付流水号、对账批次号、每日交易序号分布式自增 ID每日交易笔数、交易金额统计实时指标活动支付补贴剩余名额、营销库存扣减优势原子操作跨实例无并发问题。四、分布式集合 容器1. RBucket 通用对象容器适用场景全局支付开关、系统维护状态临时存储支付回调上下文、会话临时数据全局风控黑名单总开关2. RMap / RMapCache分布式 Map / 二级缓存适用场景支付路由表商户 ID → 支付渠道映射商户费率、支付限额、风控规则缓存支付结果临时缓存订单号 → 支付状态做防重复回调推荐RMapCache支持 TTL自动过期适配临时状态数据。3. RList适用场景待复核退款单、人工审核支付单列表流水临时排队队列简单有序列表4. RScoredSortedSet 有序集合适用场景交易金额排行榜、商户交易量排名按时间排序的异常支付单、逾期订单五、队列体系异步解耦、延迟任务支付高频1. 阻塞队列 RBlockingQueue适用场景异步记账、异步流水落地支付成功后异步通知商户、推送消息异步生成对账文件、凭证文件特点多生产者多消费者队列空则阻塞削峰填谷。2. 延迟队列 RDelayedQueue支付核心场景适用场景订单超时未支付自动关闭经典15/30 分钟关单支付成功后延迟校验、延迟对账退款申请延迟处理、账单逾期提醒预授权支付到期自动撤销流程业务侧把订单放入延迟队列指定延迟时间到期自动转入目标阻塞队列消费端监听队列执行关单 / 撤销逻辑3. 优先级队列 RPriorityQueue适用场景紧急退款、大客户优先出款风控高优拦截订单优先处理六、限流 防重 风控组件1. 分布式限流器 RRateLimiter令牌桶适用场景接口全局限流下单、支付、退款接口 QPS 控制单个商户 / 账号维度限流防刷、防恶意请求对外开放支付 API 流量管控2. 布隆过滤器 RBloomFilter适用场景支付请求防重复提交拦截重复订单号、流水号风控黑名单快速匹配海量手机号、账号拦截缓存穿透拦截判断订单 / 用户是否存在减少 DB 查询特点内存占用极低亿级数据也可高效判断。七、发布订阅 RTopic适用场景支付渠道状态变更广播银行接口宕机 / 恢复全服务感知系统配置热更新费率、路由、开关变更推送全局事件通知开始日终对账、停止对外支付八、地理空间 RGeo支付延伸场景适用场景线下门店支付、聚合支付 LBS 场景附近商户、门店定位基于地理位置的风控异地支付拦截、区域交易统计支付场景组件选用速查表业务场景推荐 Redisson 组件订单 / 钱包资金防并发、防重复操作RLock 可重入锁配置 / 费率 / 路由查询读多写少RReadWriteLock 读写锁秒杀支付、排队出款RFairLock 公平锁同时操作多个账户 / 多 Key 加锁MultiLock核心资金清分、跨节点高可靠锁RedLock 红锁支付渠道并发控制、批量任务控并发RSemaphore 信号量多子单并行处理、对账收尾RCountDownLatch 闭锁交易流水号、日交易计数RAtomicLong 原子类支付状态缓存、路由 / 费率缓存RMapCache异步记账、异步通知商户RBlockingQueue 阻塞队列订单超时未支付关闭、预授权撤销RDelayedQueue 延迟队列紧急退款、高优任务RPriorityQueue 优先级队列接口 QPS 限流、防刷RRateLimiter 限流器重复支付拦截、风控黑名单RBloomFilter 布隆过滤器渠道状态、配置热更新广播RTopic 发布订阅补充支付落地最佳实践锁粒度优先按「订单号 / 用户 ID」加锁禁止全局大锁避免性能瓶颈。延迟队列支付超时关单优先使用RDelayedQueue替代轮询查库大幅降负载。防重组合接口层RRateLimiter 布隆过滤器 分布式锁三层防重复支付。资金类强约束账户扣款、清分、调拨优先 RedLock / MultiLock提升可用性。异步解耦所有非核心链路通知、记账、日志全部走队列提升支付主链路响应速度。附录Redisson 用于支付系统的分布式锁核心原理基于Redis Lua 脚本实现主流用红锁RedLock、可重入锁、看门狗续期解决单机 / 集群环境下多实例互斥问题。一、前置为什么不用原生 RedisSETNX裸写锁原生命令redisSET lock_key uuid NX EX 30裸写存在四大致命问题不可重入同一线程再次加锁直接失败递归 / 嵌套场景崩锁超时误释放业务没跑完锁自动过期别人抢到锁锁被别人误删A 加的锁B 执行DEL直接删掉主从同步失效主节点挂了从节点没同步到锁集群丢锁Redisson 全部解决了以上问题。二、Redisson 基础可重入锁单机 / 主从架构1. 锁数据结构Hashkey锁名称如lock:orderfield线程唯一 ID 线程名称标识哪个线程持有value重入次数计数不再是简单字符串用 Hash 实现可重入。2. 加锁Lua 脚本原子执行防并发Lua 保证多条命令一次性执行中间不会被其他请求打断。逻辑锁不存在 → 新建 Hash当前线程占有设置默认过期时间默认30s返回加锁成功锁存在且是当前线程持有→ 重入次数 1返回成功锁存在且不是当前线程→ 返回失败抢锁阻塞3. 可重入实现同一线程多次lock()只累加计数不会死锁每次unlock()计数 -1计数归 0 才真正删除锁。4. 看门狗Watch Dog锁续期 —— 解决「业务超时锁自动释放」这是 Redisson 最核心设计锁默认过期时间30 秒加锁成功后后台启动定时任务看门狗每10 秒30s/3检查一次如果当前线程还持有锁 →重置锁过期时间为 30s业务正常运行 → 锁永远不会因为超时释放业务执行完毕、主动解锁 → 看门狗停止只有未手动指定 leaseTime时看门狗才生效手动传过期时间则不开启续期。5. 解锁Lua 脚本防误删逻辑原子执行判断锁是否存在、是否当前线程持有不是自己的锁 → 直接返回禁止删除解决误删问题是自己的锁 → 重入次数 -1次数 0只减计数不删锁次数 0删除整个锁 Key同时停止看门狗三、等待与阻塞机制抢锁失败怎么办抢锁失败的线程不会无限轮询低效Redisson 用Redis 发布 / 订阅Pub/Sub锁释放时主动发布消息等待中的线程收到通知再重新尝试抢锁支持tryLock(等待时间)超时抢不到直接返回 false避免死等四、Redisson 红锁 RedLockRedis 集群 / 多节点防单点故障适用场景Redis主从 哨兵仍有丢锁风险主宕机、从未同步锁多节点独立 Redis 部署用红锁。原理N 个独立 Redis 节点一般 5 个客户端依次向所有节点申请加锁成功加锁节点数 半数多数派才算整体加锁成功所有节点锁都设置较短超时防止单节点卡死解锁向所有节点统一执行解锁脚本特点容忍少数节点宕机强一致性性能比单机锁略低金融、支付等高可靠场景首选五、整体流程极简梳理单节点可重入锁线程调用lock()执行 Lua判断锁状态 → 占有 / 重入 / 等待加锁成功 → 启动看门狗定时续期业务代码执行可嵌套重入执行完毕调用unlock()Lua 减计数 → 计数为 0 删除锁、关闭看门狗发布解锁消息唤醒阻塞线程六、核心亮点总结对应原生 SETNX 缺陷✅可重入Hash 计数同一线程递归加锁没问题✅防误删解锁校验线程 ID别人删不掉你的锁✅锁自动续期看门狗业务多久锁持多久✅原子性全靠 Lua 脚本保证✅优雅阻塞Pub/Sub 通知不是死循环轮询✅高可用RedLock 多节点多数派防单点故障七、常用使用要点实战默认锁有效期30s看门狗 10s 续一次lock()阻塞抢锁tryLock()非阻塞 / 限时抢锁必须finally 里 unlock防止异常死锁多服务、多机房、高可靠场景 → 用RedLock