上一篇文章中已经介绍了我们为什么要使用mq，介绍了一些痛点问题，同时介绍了使用mq的一些好处。
引入mq后让我们子系统间耦合性降低了，异步处理机制减少了系统的响应时间，同时能够有效的应对请求峰值问题，提升系统的稳定性。
但是，引入mq同时也会带来一些问题。
3.1 重复消息问题
重复消费问题可以说是mq中普遍存在的问题，不管你用哪种mq都无法避免。
有哪些场景会出现重复的消息呢？
- 消息生产者产生了重复的消息
- kafka和rocketmq的offset被回调了
- 消息消费者确认失败
- 消息消费者确认时超时了
- 业务系统主动发起重试
如果重复消息不做正确的处理，会对业务造成很大的影响，产生重复的数据，或者导致数据异常，比如会员系统多开通了一个月的会员。
3.2 数据一致性问题
很多时候，如果mq的消费者业务处理异常的话，就会出现数据一致性问题。比如：一个完整的业务流程是，下单成功之后，送100个积分。下单写库了，但是消息消费者在送积分的时候失败了，就会造成数据不一致的情况，即该业务流程的部分数据写库了，另外一部分没有写库。
如果下单和送积分在同一个事务中，要么同时成功，要么同时失败，是不会出现数据一致性问题的。
但由于跨系统调用，为了性能考虑，一般不会使用强一致性的方案，而改成达成最终一致性即可。
3.3 消息丢失问题
同样消息丢失问题，也是mq中普遍存在的问题，不管你用哪种mq都无法避免。
有哪些场景会出现消息丢失问题呢？
- 消息生产者发生消息时，由于网络原因，发生到mq失败了。
- mq服务器持久化时，磁盘出现异常
- kafka和rocketmq的offset被回调时，略过了很多消息。
- 消息消费者刚读取消息，已经ack确认了，但业务还没处理完，服务就被重启了。
导致消息丢失问题的原因挺多的，生产者、mq服务器、消费者 都有可能产生问题，我在这里就不一一列举了。最终的结果会导致消费者无法正确的处理消息，而导致数据不一致的情况。
3.4 消息顺序问题
有些业务数据是有状态的，比如订单有：下单、支付、完成、退货等状态，如果订单数据作为消息体，就会涉及顺序问题了。如果消费者收到同一个订单的两条消息，第一条消息的状态是下单，第二条消息的状态是支付，这是没问题的。但如果第一条消息的状态是支付，第二条消息的状态是下单就会有问题了，没有下单就先支付了？
消息顺序问题是一个非常棘手的问题，比如：
- kafka同一个partition中能保证顺序，但是不同的partition无法保证顺序。
- rabbitmq的同一个queue能够保证顺序，但是如果多个消费者同一个queue也会有顺序问题。
如果消费者使用多线程消费消息，也无法保证顺序。
如果消费消息时同一个订单的多条消息中，中间的一条消息出现异常情况，顺序将会被打乱。
还有如果生产者发送到mq中的路由规则，跟消费者不一样，也无法保证顺序。
3.5 消息堆积
如果消息消费者读取消息的速度，能够跟上消息生产者的节奏，那么整套mq机制就能发挥最大作用。但是很多时候，由于某些批处理，或者其他原因，导致消息消费的速度小于生产的速度。这样会直接导致消息堆积问题，从而影响业务功能。
这里以下单开通会员为例，如果消息出现堆积，会导致用户下单之后，很久之后才能变成会员，这种情况肯定会引起大量用户投诉。
3.6 系统复杂度提升
这里说的系统复杂度和系统耦合性是不一样的，比如以前只有：系统A、系统B和系统C 这三个系统，现在引入mq之后，你除了需要关注前面三个系统之外，还需要关注mq服务，需要关注的点越多，系统的复杂度越高。
mq的机制需要：生产者、mq服务器、消费者。
有一定的学习成本，需要额外部署mq服务器，而且有些mq比如：rocketmq，功能非常强大，用法有点复杂，如果使用不好，会出现很多问题。有些问题，不像接口调用那么容易排查，从而导致系统的复杂度提升了。
那么，引入mq之后带来的这些问题该如何解决呢？
我们下回分解。
