系统中使用MQ可能带来的问题

在前面的问题中说了为什么要使用mq中间件的问题，但任何系统每引入一个中间件，就代表着系统的复杂性升高了，也就会带来一些之前不存在的问题；比如，中间件系统崩溃导致的服务不可用，或者数据丢失等问题，那么使用mq系统可能会带来哪些问题呢？

使用mq虽然带来了很多方便，但同时也带来了很多问题，而最常见的问题就是：

1. 重复消费的问题

2. 数据一致性问题

3. 顺序消费问题

4. 消息堆积问题

那碰到这些问题应该怎么解决呢？

1. 关于重复消费的问题，最简单也是最通用的解决方案就是使用幂等，根据不同的业务场景，在消费端加一个幂等验证，即使用业务中唯一标识，比如业务模块+订单号的方式，消费者再进行业务逻辑处理之前，先判断这个唯一标识是否已经被处理过，如果已经被处理过则直接返回。

2. 关于数据一致性问题，就是mq可能由于系统崩溃或其它原因导致数据丢失，最后导致出现数据一致性问题；而从逻辑上来说，在生产端，消费端和服务器端都可能导致数据丢失的问题出现；比如生产者发送消息时由于网络原因导致发送失败，这个时候就需要在生产端加上异常处理；而服务器端可能出现系统崩溃，硬盘爆满又或者是硬盘损坏等，这时为了保证安全性就需要使用集群部署加持久化；而消费端的数据丢失，比如消费者读取消息之后，还没开始消费，消费者的服务就因为某个原因挂掉了，这时就会导致消费端的数据丢失，而解决办法就是加上消费消费成功验证。

3. 关于顺序消费的问题，没有一个完善的解决办法，首先是因为顺序消费的场景并不是很多，其次，不同的mq服务有不同的实现顺序消费的方式，比如kafka服务在同一个part中的消息是有序的，但不同part之间的消息是无序，那么在生产端就要保证顺序消息要被发送到同一个part中；但生产端保证同一个part中的消息就一定会被顺序消费吗？这是不一定的，假如有多个消费者同时订阅一个part中消息，因为每个消费者的性能不一样，也就导致消息的顺序不一样；或者同一个消费者中使用了异步多线程的方式处理数据，也会导致顺序消费的问题。而且，如果只使用一个part进行顺序消费，如果数据量很大的情况下就会导致性能问题。所以，顺序消费需要根据不同的业务场景和数据量进行个性化设计。

4. 关于消息堆积问题，说白了就是因为生产端消息生产太快，而消费端消费速度根本上；比如消费端本来有五个消费者在同时工作，但由于某些原因导致其中四个消费者挂掉了，这时消费端的消费速度就严重下降，导致消息堆积。这时可以通过控制生产端的消息生产速度或者增加消费者数量来解决这个问题。

所以说，使用中间件带来各种方便的同时，也带来各种问题；而我们只能不同业务场景进行不同的处理，主打的一个就是实事求是。