什么是MQ?

消息队列(MQ)，是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信，而无需专用连接来链接它们。

消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

扩展资料：

MQ传递主干，在世界屡获殊荣。 它帮您搭建企业服务总线(ESB)的基础传输层。IBM WebSphere MQ为SOA提供可靠的消息传递。它为经过验证的消息传递主干， 全方位、 多用途的数据传输， 并帮助您搭建企业服务总线的传输基础设施。

IBM WebSphere MQ 支持两种不同的应用程序编程接口：Java 消息服务（JMS）和消息队列接口（MQI）。在 IBM WebSphere MQ 服务器上，JMS 绑定方式被映射到 MQI。

应用程序直接与其本地队列管理器通过使用 MQI 进行对话，MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供 13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口，因为大部分艰苦工作都将透明完成的。

IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、操作系统以及通信协议的网络彼此进行通信。

参考资料：百度百科-MQ

1，为什么要用mq？

2，引入mq会多哪些问题？

3，如何解决这些问题？

---

一：传统模式有哪些痛点

（1）有些复杂的业务系统，一次用户请求可能会同步调用N个系统的接口，需要等待所有的接口都返回了，才能真正的获取执行结果。这种同步接口调用的方式总耗时比较长，非常影响用户的体验，特别是在网络不稳定的情况下，极容易出现接口超时问题。

（2）系统之间耦合性太高，如果调用的任何一个子系统出现异常，整个请求都会异常，对系统的稳定性非常不利。

（3）对于类似于秒杀场景的峰值爆炸的场景，系统的稳定性堪忧；

二：为什么要用mq？

（1）异步：同步接口调用导致响应时间长的问题，使用mq之后，将同步调用改成异步，能够显著减少系统响应时间。避免耗时时间长，影响用户体验的事情发生

（2）解耦：子系统间耦合性太大的问题，使用mq之后，我们只需要依赖于mq，避免了各个子系统间的强依赖问题。这样就把之前复杂的业务子系统的依赖关系，转换为只依赖于mq的简单依赖，从而显著的降低了系统间的耦合度。

（3）削峰：由于突然出现的请求峰值，导致系统不稳定的问题。使用mq后，能够起到消峰的作用。

订单系统接收到用户请求之后，将请求直接发送到mq，然后订单消费者从mq中消费消息，做写库操作。如果出现请求峰值的情况，由于消费者的消费能力有限，会按照自己的节奏来消费消息，多的请求不处理，保留在mq的队列中，不会对系统的稳定性造成影响。

三：引入mq会出现哪些问题：

1，重复消息问题

重复消费问题可以说是mq中普遍存在的问题，不管你用哪种mq都无法避免。

有哪些场景会出现重复的消息呢？

消息生产者产生了重复的消息

kafka和rocketmq的offset被回调了

消息消费者确认失败

消息消费者确认时超时了

业务系统主动发起重试

如果重复消息不做正确的处理，会对业务造成很大的影响，产生重复的数据，或者导致数据异常；

（2）数据一致性问题

如果mq的消费者业务处理异常的话，就会出现数据一致性问题。

比如：一个完整的业务流程是，下单成功之后，送100个积分。下单写库了，但是消息消费者在送积分的时候失败了，就会造成数据不一致的情况，即该业务流程的部分数据写库了，另外一部分没有写库。

如果下单和送积分在同一个事务中，要么同时成功，要么同时失败，是不会出现数据一致性问题的。

但由于跨系统调用，为了性能考虑，一般不会使用强一致性的方案，而改成达成最终一致性即可。

（3）消息丢失问题：

哪些场景会出现消息丢失问题呢？

消息生产者发生消息时，由于网络原因，发生到mq失败了。

mq服务器持久化时，磁盘出现异常

kafka和rocketmq的offset被回调时，略过了很多消息。

消息消费者刚读取消息，已经ack确认了，但业务还没处理完，服务就被重启了。

导致消息丢失问题的原因挺多的，生产者、mq服务器、消费者 都有可能产生问题，我在这里就不一一列举了。最终的结果会导致消费者无法正确的处理消息，而导致数据不一致的情况。

（4）消息顺序问题

有些业务数据是有状态的，比如订单有：下单、支付、完成、退货等状态，如果订单数据作为消息体，就会涉及顺序问题了。如果消费者收到同一个订单的两条消息，第一条消息的状态是下单，第二条消息的状态是支付，这是没问题的。但如果第一条消息的状态是支付，第二条消息的状态是下单就会有问题了，没有下单就先支付了？

消息顺序问题是一个非常棘手的问题，比如：

kafka同一个partition中能保证顺序，但是不同的partition无法保证顺序。

rabbitmq的同一个queue能够保证顺序，但是如果多个消费者同一个queue也会有顺序问题。

如果消费者使用多线程消费消息，也无法保证顺序。

如果消费消息时同一个订单的多条消息中，中间的一条消息出现异常情况，顺序将会被打乱。

还有如果生产者发送到mq中的路由规则，跟消费者不一样，也无法保证顺序。

（5）消息堆积问题

如果消息消费者读取消息的速度，能够跟上消息生产者的节奏，那么整套mq机制就能发挥最大作用。但是很多时候，由于某些批处理，或者其他原因，导致消息消费的速度小于生产的速度。这样会直接导致消息堆积问题，从而影响业务功能。

这里以下单开通会员为例，如果消息出现堆积，会导致用户下单之后，很久之后才能变成会员，这种情况肯定会引起大量用户投诉。

（6）系统复杂度提升

这里说的系统复杂度和系统耦合性是不一样的，比如以前只有：系统A、系统B和系统C 这三个系统，现在引入mq之后，你除了需要关注前面三个系统之外，还需要关注mq服务，需要关注的点越多，系统的复杂度越高。

mq的机制需要：生产者、mq服务器、消费者。

有一定的学习成本，需要额外部署mq服务器，而且有些mq比如：rocketmq，功能非常强大，用法有点复杂，如果使用不好，会出现很多问题。有些问题，不像接口调用那么容易排查，从而导致系统的复杂度提升了。

如何解决？

1，重复消费问题的解决：

不管是由于生产者产生的重复消息，还是由于消费者导致的重复消息，我们都可以在消费者中这个问题。

这就要求消费者在做业务处理时，要做幂等设计；

在这里我推荐增加一张消费消息表，来解决mq的这类问题。消费消息表中，使用messageId做唯一索引，在处理业务逻辑之前，先根据messageId查询一下该消息有没有处理过，如果已经处理过了则直接返回成功，如果没有处理过，则继续做业务处理。

2，数据一致性的解决：

数据一致性分为：

强一致性

弱一致性

最终一致性

而mq为了性能考虑使用的是最终一致性，那么必定会出现数据不一致的问题。这类问题大概率是因为消费者读取消息后，业务逻辑处理失败导致的，这时候可以增加重试机制。

重试分为：同步重试 和 异步重试。

有些消息量比较小的业务场景，可以采用同步重试，在消费消息时如果处理失败，立刻重试3-5次，如何还是失败，则写入到记录表中。但如果消息量比较大，则不建议使用这种方式，因为如果出现网络异常，可能会导致大量的消息不断重试，影响消息读取速度，造成消息堆积。

而消息量比较大的业务场景，建议采用异步重试，在消费者处理失败之后，立刻写入重试表，有个job专门定时重试。

还有一种做法是，如果消费失败，自己给同一个topic发一条消息，在后面的某个时间点，自己又会消费到那条消息，起到了重试的效果。如果对消息顺序要求不高的场景，可以使用这种方式。

3，消息丢失问题

不管你是否承认有时候消息真的会丢，即使这种概率非常小，也会对业务有影响。生产者、mq服务器、消费者都有可能会导致消息丢失的问题。

为了解决这个问题，我们可以增加一张消息发送表，当生产者发完消息之后，会往该表中写入一条数据，状态status标记为待确认。如果消费者读取消息之后，调用生产者的api更新该消息的status为已确认。有个job，每隔一段时间检查一次消息发送表，如果5分钟（这个时间可以根据实际情况来定）后还有状态是待确认的消息，则认为该消息已经丢失了，重新发条消息。

4，消息顺序问题

消息顺序问题是我们非常常见的问题，我们以kafka消费订单消息为例。订单有：下单、支付、完成、退货等状态，这些状态是有先后顺序的，如果顺序错了会导致业务异常。

订单号路由到不同的partition，同一个订单号的消息，每次到发到同一个partition。

5，消息堆积

如果消费者消费消息的速度小于生产者生产消息的速度，将会出现消息堆积问题。其实这类问题产生的原因很多，如果你想进一步了解，可以看看我的另一篇文章《 我用kafka两年踩过的一些非比寻常的坑 》。

那么消息堆积问题该如何解决呢？

这个要看消息是否需要保证顺序。

如果不需要保证顺序，可以读取消息之后用多线程处理业务逻辑。

这样就能增加业务逻辑处理速度，解决消息堆积问题。但是线程池的核心线程数和最大线程数需要合理配置，不然可能会浪费系统资源。

如果需要保证顺序，可以读取消息之后，将消息按照一定的规则分发到多个队列中，然后在队列中用单线程处理。

消息队列(MQ)，是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信，而无需专用连接来链接它们。

消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

扩展资料：

MQ传递主干，在世界屡获殊荣。 它帮您搭建企业服务总线(ESB)的基础传输层。IBM WebSphere MQ为SOA提供可靠的消息传递。它为经过验证的消息传递主干， 全方位、 多用途的数据传输， 并帮助您搭建企业服务总线的传输基础设施。

IBM WebSphere MQ 支持两种不同的应用程序编程接口：Java 消息服务（JMS）和消息队列接口（MQI）。在 IBM WebSphere MQ 服务器上，JMS 绑定方式被映射到 MQI。

应用程序直接与其本地队列管理器通过使用 MQI 进行对话，MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供 13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口，因为大部分艰苦工作都将透明完成的。

IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、操作系统以及通信协议的网络彼此进行通信。

参考资料：百度百科-MQ

---