消息中间件是什么？有什么用？常见的消息中间件有哪些？

1.什么是消息中间件？

消息中间件基于队列模型在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。

2.现实中的痛点：

1.Http请求基于请求与响应的模型，在高并发的情况下，客户端发送大量的请求达到服务器端有可能会导致我们服务器端处理请求堆积。

2.Tomcat服务器处理每个请求都有自己独立的线程，如果超过最大线程数会将该请求缓存到队列中，如果请求堆积过多的情况下，有可能会导致tomcat服务器崩溃的问题。

所以一般都会在nginx入口实现限流，整合服务保护框架。

3.http请求处理业务逻辑如果比较耗时的情况下，容易造成客户端一直等待，阻塞等待过程中会导致客户端超时发生重试策略，有可能会引发幂等性问题。

注意事项：接口是为http协议的情况下，最好不要处理比较耗时的业务逻辑，耗时的业务逻辑应该单独交给多线程或者是mq处理。

3.消息中间件的作用：

可以实现支撑高并发、异步解耦、流量削峰、降低耦合度。

3.1 支撑高并发

在高并发环境下，如果消息的处理速度跟不上消息的生成速度，就会导致消息队列堆积，进而影响系统的稳定性和可用性。为了解决这个问题，引入消息限流策略是非常必要的。

消息限流是一种通过控制消息的生成速率和处理速率来平衡生产者和消费者之间的关系。通过设置合理的限流参数，可以控制系统的负载，避免资源耗尽和系统崩溃的风险。

RabbitMQ与消息限流策略的结合

1、预取计数（prefetch count）：RabbitMQ中的预取计数可以控制消费者从队列中获取消息的数量。通过合理设置预取计数，可以平衡生产者和消费者之间的速率差异。当消费者处理完预取的消息后，才会继续从队列中获取新的消息，这样可以避免消息的堆积。

2、限制连接数和通道数：在RabbitMQ中，可以通过限制连接数和通道数来控制消息的生成速度和处理速度。通过限制连接数，可以限制生产者的连接数，控制消息的生成速度；通过限制通道数，可以提高消费者的处理速度，避免系统负载过高。

3、延迟队列（dead-letter queue）：延迟队列是一种特殊的队列，用于存放无法立即处理的消息。当消息到达延迟队列后，可以设置一个延迟时间，在延迟时间过后再将消息重新发送给消费者进行处理。通过延迟队列，可以有效控制消息的处理速率，尤其适用于对实时性要求不高的场景。

3.2 异步解耦

应用场景：一般用于用户注册后，需要发送注册邮件和注册短信

传统做法：

1.串行方式

串行的方式就是将注册信息写入数据库后，发送注册邮件，再发送注册短信，以上三个任务全部完成后才返回给客户端。这有一个问题是，邮件，短信并不是必须的，它只是一个通知，而这种做法让客户端等待没有必要等待的东西。

2.并行方式

将注册信息写入数据库后，同时执行发送邮件，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间。

假设三个业务节点分别使用50ms，串行方式使用时间150ms，并行使用时间100ms。虽然并性已经提高的处理时间，但是，前面说过邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功，应该是写入数据库后就返回。

3.消息队列的方式

引入消息队列之后就可以异步处理发送注册邮件和注册短信的业务，在注册信息写入数据库之后，这些不妨碍用户使用的业务，先加入到消息队列当中等待处理。

由此可见引入消息队列之后，响应时间=数据库写入时间+写入消息队列的时间，消息队列中的消息可以等待前面的消息处理完再处理。

3.3 降低耦合度

应用场景：商城活动时，下单高峰时期，用户下单，订单业务模块调用库存业务模块的接口。

这种情况下就会存在订单业务和库存业务高度耦合的问题，一旦我们的库存业务使用不了了，那我i们的订单业务也就无法使用了。引入消息队列就可以解决这一问题：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。

库存系统：订阅下单的消息，获取下单消息，进行库操作。

就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失。

3.4 流量削峰

应用场景：流量削峰一般用于秒杀活动中。秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，一般在应用前端加入消息队列。

作用：

1、可以控制活动人数，超过限制就会直接丢弃掉后来的订单

2、可以缓解短时间的高流量（超出服务器承受范围）压垮服务器

1、用户的请求，服务器收到之后，首先写入消息队列，加入消息队列长度超过最大值，则直接抛弃用户请求或跳转到错误页面。

2、秒杀业务根据消息队列中的请求信息，再做后续处理。

3.5 消息队列优缺点

关于消息队列的优点也就是上面列举的，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下几个：

1.系统可用性降低：系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？如何保证消息队列的高可用，可以点击这里查看。

2.系统复杂度提高：硬生生加个 MQ 进来，你怎么[保证消息没有重复消费]？怎么[处理消息丢失的情况]？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

3.一致性问题：A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

4. 常见的消息中间件

在介绍常见的消息中间件的方式的时候先介绍一下实现MQ的两种方式：AMQP，JMS

4.1 AMQP和JMS

AMQP全称Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件传递消息，不受客户端/中间件不同产品、不同开发语言等条件的限制。该协议是一种二进制协议，提供客户端应用于消息中间件之间异步、安全、高效的交互。相对于我们常见的REST API，AMQP更容易实现，可以降低开销，同时灵活性高，可以轻松的添加负载平衡和高可用性的功能，并保证消息传递，在性能上AMQP协议也相对更好一些。（官方解释）

通俗来说，在异步通讯中，消息不会立刻到达接收方，而是被存放到一个容器中，当满足一定的条件之后，消息会被容器发送给接收方，这个容器即消息队列，而完成这个功能需要双方和容器以及其中的各个组件遵守统一的约定和规则，AMQP就是这样的一种协议，消息发送与接收的双方遵守这个协议可以实现异步通讯。这个协议约定了消息的格式和工作方式。

JMS即Java消息服务（Java Message Service）应用程序接口，是一个 Java 平台中关于面向消息中间件（MOM）的API，用于在两个应用程序间或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。简单的理解：两个应用程序之间需要进行通信，使用一个JMS服务，进行中间的转发，通过JMS 的使用，可以解除两个程序之间的耦合。

两者间的区别和联系：