消息中间件MQ之JMS学习

1. 引入

远程调用是同步的， 出现一些问题：

1. 是同步阻塞的，客户对象发出调用后，必须等待服务对象完成处理并返回结果才能继续 执行；
2. 是紧密耦合的，客户进程和服务对象进行都必须正常运行，服务对象的崩溃会导致客户 对象的异常。
3. 点对点：客户对象一次只能发送给一个目标对象。

**面向消息的中间件（Message Oriented Middleware，MOM）**使用异步手段有效的解决 以上问题：“消息发送者”将消息发送给“消息服务器”，“消息服务器”将消息存放在若干“队 列”中，在合适的时候再将消息转发给接收者。

特点：

• 发送和接收是异步的，发送者无需等待。
• 二者松耦合：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定 运行。
• 一对多：对于一个消息可以有多个接收者。

2. 消息中间件的使用场景

消息中间件的使用场景总结就是六个字：解耦、异步、削峰。

2.1 解耦

如果我方系统A要与三方B系统进行数据对接，推送系统人员信息，通常我们会使用接口开发来进行。但是如果运维期间B系统进行了调整，或者推送过程中B系统网络进行了调整，又或者后续过程中我们需要推送信息到三方C系统中，这样的话就需要我们进行频繁的接口开发调整，还需要考虑接口推送消息失败的场景。

如果我们使用消息中间件进行消息推送，我们只需要按照一种约定的数据结构进行数据推送，其他三方系统从消息中间件取值消费就可以，即便是三方系统出现宕机或者其他调整，我们都可以正常进行数据推送。

总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。

2.2 异步

继续我们上述的消息推送业务，如果我们现在需要同时推送消息到BCD三个系统中，而BCD系统接收到消息后需要进行复杂的逻辑处理，以及读库写库处理。如果一个三方系统进行消息处理需要1s，那我们遍历推送完一次消息，就需要三秒。

而如果我们使用消息中间件，我们只需要推送到消息中间件，然后进行接口返回，可能只需要20ms，大大提升了用户体验。消息推送后BCD系统各自进行消息消费即可，不需要我们等待。

2.3 削峰

还是上述我们的应用场景，假设某一时间段内，每秒都有一条消息推送，如果我们使用接口进行推送，BCD三个系统处理完就需要三秒。这样会导致用户前端体验较差，而且系统后台一直处于阻塞状态，后续的消息推送接口一直在等待。

如果我们使用消息中间件，我们只需要将消息推送至消息中间件中，BCD系统对积压的消息进行相应的处理。

在上述高频发的消息时间段内，会在消息中间中产生消息积压，BCD系统在上述时间段外对积压消息进行相应的处理即可。

3. 消息中间件的优缺点

消息中间件的缺点与优点也是相辅相成的，主要有以下三个：

1. 系统可用性降低

系统关联的中间件越多，越容易引发宕机问题。
如上述案例中的问题，原本进行消息推送我们只需要开发接口进行推送即可，引入消息中间件后就需要考虑消息中间件的高可用问题，如果消息中间件出现宕机问题，我们所有的消息推送都会失败。

2. 系统复杂度提高

上述案例中，如果我们使用接口进行消息推送，我们只需要考虑接口超时以及接口推送消息失败的问题。但我们引入消息中间件后，就需要考虑消息中间件的维护，以及消息重复消费，消息丢失的问题。