解决一个问题,往往会引发别的问题。
反过来想,若消息队列实现了exactly once,会引发的问题有:
消费端在消费时,则需要增加逻辑判断来检测此消息是否被消费,检查机制还需要业务端去配合实现,若一条消息长时间未返回ack,消息队列需要去回调看下消费结果。这个检测机制无疑会拉低消息消费的速度。
随着消息的剧增,消费性能势必会急剧下降,导致消息积压;
若消息队列实现exactly once,会怎样
而消息队列实现exactly once本身也需要一定成本:因为消息的唯一性是业务定义的,消息队列如果要保证exactly once,需要感知业务(本文中幂等的做法,都是在业务上给出了消息唯一性的定义),这样消息队列就与业务系统就会有耦合。消息队列作为中间件,是不应该和业务系统产生耦合的。
所以,消息队列不实现exactly once,而是 at least once + 幂等性
从业务逻辑设计上入手来,将消费的业务逻辑设计成幂等
- 数据库唯一性的约束
- sql乐观锁设计
- 业务唯一性id利用分布式锁redis来处理