-
一个没做幂等的消息队列消费者,因为一次网络抖动把同一条扣款消息消费了两次,给用户活生生扣了两次钱:一次消息重复消费与幂等缺失的深度复盘
半夜被叫醒处理资损:一笔订单被扣了两次款,有两条几乎一致的扣款流水,可同一笔订单我们只发了一条扣款消息。翻 MQ 投递日志才看清:消息队列是 at-least-once(至少一次)投递、宁可重复不愿丢消息,那次扣款服务已成功扣款,但返回 ack 时网络抖动、ack 没送达,MQ 以为没处理成功便重新投递,而消费者没做幂等、又扣了一次。本文讲透 MQ 三种投递语义与为何必须幂等,给出数据库唯一约束/…- 0
- 0
-
一个 Redis 分布式锁的过期时间没扛住业务耗时,锁提前自动释放让两个线程同时进了临界区、还互相误删了对方的锁:一次分布式锁失效的深度复盘
用 Redis 分布式锁保证同一笔账只有一个节点处理,跑了大半年都好好的,直到对账量大、业务跑了 40 秒、超过了锁的 30 秒过期时间——锁中途自动释放,第二个线程进了临界区两线程同时处理,第一个线程干完 del 又删掉了第二个线程的锁,锁彻底形同虚设。本文讲透分布式锁的两大核心难题(过期时间两难、误删),给出唯一标识+Lua 原子校验删除防误删、看门狗自动续期解决过期、生产用 Redisson…- 0
- 0
系统架构
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×