如何解决 顺序消费、重复消费

如何进行顺序消费

首先对于顺序消费我们无法保障全局的顺序消费，只能保障局部的顺序消费，对于RocketMQ来说是保障同一个queue内的消费顺序，对于kafka来说是保障同一个partition内顺序消费。在发送消息时默认会根据发送时设置的key进行计算得到消息应该落在哪个partition或者queue内。所以我们在保障局部顺序消费时就是根据的这个原则来保障的。

如果真要保障全局顺序那么可能就是对于某个topic它的partition为1.

如何防止重复消费

消息发送端保障不重复发送消息

生产端保障不要重复投递MQ消息，业务上做数据投递成功的校验，如果是APP|WEB客户端保障客户端不要出现表单重复提交。

对于RocketMQ而言，发送端有同步发送、异步发送、异步回调发送，对于同步发送会降低发送端的吞吐量，以及发送过程的响应时间，但是相对数据安全来说比较有保障。而对于异步发送，由于发送完消息后并没等待MQ服务端ACK相应，所以这里数据安全来说比较没保障，可能出现消息丢失，但是执行效率较高。但是即使使用同步发送的方式，但是当遇到网络问题时，命名MQ服务端已经接收了消息，但是客户端接收ACK时网络异常，但是客户端再次发送也是存在的。所以无论采用哪种方式依然存在客户端重复发送消息的问题。
所以我们是否可以考虑在业务上采用异步发送的方式+采用定时检查(根据业务每隔多久检查发送到MQ的消息是否已经执行完成回调，没回调认为是没投递成功，再次投递。但是无论业务如这个时间如何经过多次验证，但是还是会随着系统、业务的迭代出现各种问题导致重复投递)的方式来保障消息的可靠性投递。

另外针对消息丢失还可能是由于MQ的刷盘方式采用异步刷盘导致的。所以这里采用定时器来做一层保障更能保障消息的可靠性投递。

消息消费端保障不重复消息

首先这里先说明下，消费端消费消息时涉及到ACK响应时机，有获取消息时就响应ACK(这种方式消费端吞吐量大，但是如果执行消息失败，那么就意味着消息丢失了)，有执行结束后响应ACK(这种方式消费端吞吐量低，但是比较有保障消息失败时不丢失)。无论哪种方式依然存在ACK响应失败导致重复消费(当消费端成功消费后响应ACK，但是由于网路问题导致MQ服务端无法接收ACK，误以为消费失败，所以该消息再次被消费)。所以消费端进行幂等保障是必不可少的操作。

根据刚才的讲述我们知道要保障消息的可靠性投递不可避免的会出现消息的重复投递，这时候就需要在服务端进行幂等消费保障。典型的方案就是每个消息中都会携带着业务唯一ID，可以根据业务唯一ID查询数据表看是否消费过，如果消费过那么就是消费过，日志记录，直接返回ACK。如果未消费过则加分布式锁，然后再次验证是否消费过(因为担心出现极端现象，两条重复的消息连在一起，并且消费端响应ACK是在获取消息后)。如果成功消费过则不处理，记录日志。如果未消费过，则执行消费逻辑。

总结

通过上面的描述我们可以看出在系统引入MQ后，虽然对我们带来了好处，但是如果要保障消息的可靠性投递以及防止重复消费，那么系统的复杂度真的是提高了好多，整个业务代码量要增加很多。并且为了对异常场景进行监控，又要加入很多的监控点，简直是程序员的噩梦。所以一项技术的引入是为了解决当前不可避免的问题，但是同时还会带来新的问题。对于引入新技术的了解深度是必不可少的，这样才能避免尽量少踩坑。