为什么大部分消息队列都选择只提供 At least once 的服务质量，而不是级别更高的 Exactly once 呢

解决一个问题，往往会引发别的问题。
我们需要容忍存在的设计缺陷，并且找到该问题存在的原因。
若消息队列实现了exactly once，会引发的问题有：
消费端在消费时，则需要增加逻辑判断来检测此消息是否被消费，检查机制还需要业务端去配合实现，若一条消息长时间未返回ack，消息队列需要去回调看下消费结果。这个检测机制无疑会拉低消息消费的速度。
随着消息的剧增，消费性能势必会急剧下降，导致消息积压；

若消息队列如何实现exactly once？
而消息队列实现exactly once本身也需要一定成本：因为消息的唯一性是业务定义的，消息队列如果要保证exactly once，需要感知业务（本文中幂等的做法，都是在业务上给出了消息唯一性的定义），这样消息队列就与业务系统就会有耦合。消息队列作为中间件，是不应该和业务系统产生耦合的。

所以，消息队列不实现exactly once，而是at least once + 幂等性
从业务逻辑设计上入手来，将消费的业务逻辑设计成幂等
1.数据库唯一性的约束
2.sql乐观锁设计
3.业务唯一性id利用分布式锁redis来处理