消费端幂等性保障
在海量消息产生的业务高峰期,应当避免消费端的消息重复消费,方案与数据库乐观锁和Redis分布式锁思路一致
幂等性不对等情景:
-
生产端发送消息到 broker 了,broker 也给响应了,但是 confirm 的时候出现网络闪断,生产端没收到该消息 ACk 导致兜底的定时任务再次发送消息
-
MQ Broker 服务与消费端传输消息的过程中发生了网络抖动影响到了
-
消费端故障或异常
方案:
唯一ID+指纹码机制:
使用雪花算法、Tinyid 等生成唯一ID给消息标识和指纹码,消息入库时作为主键进行保存,因此保证消息唯一性
优点:实现简单
缺点:
1、高并发业务下游数据库有写入性能瓶颈
2、需要本地ID生成服务,确保外部统一生成ID服务无法使用时可以进行兜底
解决方案:数据库进行分库分表,对消息ID使用算法解析路由到不同的数据库中
唯一ID+指纹码方案架构
Redis 原子性 :
利用 redis 执行 setnx 命令,天然具有幂等性。从而实现不重复消费
优点:性能高,AOF模式数据不丢失
缺点:
1、数据同步入库需要考虑到数据库和Redis之间的原子性
2、消息不同步入库,Redis定时同步到数据库的策略需要具体设计