MQ 消息队列
在微服务架构中，MQ（Message Queue，消息队列）扮演着至关重要的角色。MQ 是一种跨进程的通信机制，通常用于应用程序间进行数据的异步传输，也被称作“消息中间件”。在微服务架构中，MQ 的主要作用包括服务间的解耦、异步通信、流量削峰和数据同步等。
一、MQ 在微服务中的作用
- 服务解耦：
- 微服务架构中，各个服务之间往往存在复杂的依赖关系。通过使用 MQ，服务之间的直接调用被消息传递所替代，从而降低了服务间的耦合度。
- 当一个服务需要调用另一个服务时，只需将请求消息发送到 MQ 中，由 MQ 负责将消息转发给目标服务，而无需服务之间直接进行通信。
- 异步通信：
- MQ 允许服务之间进行异步通信，即服务发送方无需等待服务接收方的响应即可继续执行后续操作。
- 这种机制提高了系统的响应速度和吞吐量，因为服务不会因等待响应而被阻塞。
- 流量削峰：
- 在高并发场景下，MQ 可以作为缓冲层，暂存无法及时处理的请求消息。
- 这样，当系统负载较高时，可以通过 MQ 来平滑处理请求，避免系统因过载而崩溃。
- 数据同步：
- MQ 还可以用于实现不同服务之间的数据同步。
- 通过将需要同步的数据发送到 MQ，再由目标服务从 MQ 中获取数据进行处理，可以实现数据在不同服务之间的实时或准实时同步。
二、常用的 MQ 产品
三、RabbitMQ
安装插件并启动 根据其路径可以访问界面化控制台
publisher-->exchange-->queue-->consumer
java客户端的使用
Spring AMQP(二次封装AMQP)
1. 引入依赖spring-boot-starter-amqp
2. 配置rabbitmq服务端信息
3. 利用RabbitTemplate发送信息
4.利用@RabbitListener注解声明要监听的队列，监听消息
消费者消息推送限制
默认情况下RabbitMQ会将消息轮询投递给绑定到队列的每一个消费者，没有考虑消费者的处理速度，可能出现消息堆积
work模型的使用：
多个消费者绑定一个队列，可以加快消息处理速度
同一个消息只会被一个消费者处理
通过设置profetch来控制消费者的预读的消息数量，处理完一条再处理下一条，能者多劳
交换机
1.Fanout 交换机
扇形交换机：将消息广播到交换价绑定的所有队列，无视消息的路由键
2.Direct交换机
直连交换机：将接收到的消息根据规则路由到指定的Queue，也称为定向路由
3.Topic交换机
主题交换机：使用通配符匹配路由键，允许更灵活的消息路由
代码实现交换机以及绑定队列
bean实现
注解实现
通过 @RabbitListener 的 bindings 属性声明 Binding（若 RabbitMQ 中不存在该绑定所需要 的 Queue、Exchange、RouteKey 则自动创建，若存在则抛出异常）
消息转换器 默认用到jkd的序列化 占用内存大，可读性差（控制台） 引入json相关依赖
可靠性
发送者
1.发送者重连
描述：（默认关闭）由于网络波动，可能出现发送者连接MQ失败的情况，需要重新连接
配置：
改方式提高了消息发送成功的概率。但其用的阻塞式重连，降低了性能，要用的话可以考虑异步
2.发送者确认
MQ可靠性
1.数据持久化
为了提升性能，默认情况下MQ的数据都是在内存存储的临时数据，重启后就会消失。为了保证数据的可靠性，必须配置数据持久化，包括：
一旦出现消息堆积问题，RabbitMQ的内存占用就会越来越高，直到触发内存预警上限。此时RabbitMQ会将内存消息刷到磁盘上，这个行为成为PageOut. PageOut会耗费一段时间，并且会阻塞队列进程。因此在这个过程中RabbitMQ不会再处理新的消息，生产者的所有请求都会被阻塞。
为了解决这个问题，从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的模式，也就是惰性队列。惰性队列的特征如下：
而在3.12版本之后，LazyQueue已经成为所有队列的默认格式。因此官方推荐升级MQ为3.12版本或者所有队列都设置为LazyQueue模式。
消费者可靠性
交换机持久化
队列持久化
消息持久化
2.LazyQueue
在默认情况下，RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟。但在某些特殊情况下，这会导致消息积压，比如：
消费者宕机或出现网络故障
消息发送量激增，超过了消费者处理速度
消费者处理业务发生阻塞
接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存（也就是懒加载）
支持数百万条的消息存储
Mq的消费者可靠性是确保消息在消费过程中不丢失、正确处理且能够应对异常情况的重要方面。以下是从几个方面详细阐述Mq消费者可靠性的内容：
1、消费者确认机制
RabbitMQ等消息队列提供了消费者确认机制（Consumer Acknowledgement），即当消费者处理消息结束后，应该向MQ发送一个回执，告知MQ消息处理的状态。回执有三种可选值：
- ack：表示成功处理消息，MQ将从队列中删除该消息。
- nack：表示消息处理失败，MQ需要再次投递消息。
- reject：表示消息处理失败并拒绝该消息，MQ将从队列中删除该消息。
2、消息重试机制
在消费者处理消息的过程中，可能会遇到暂时性的错误（如网络波动、数据库连接问题等），导致消息处理失败。为了应对这种情况，MQ通常提供了消息重试机制。当消费者处理消息失败时，MQ可以根据配置将消息重新投递给消费者进行重试。
- 重试次数：可以配置重试的次数，以确保在有限的次数内能够成功处理消息。
- 重试间隔：可以配置每次重试之间的时间间隔，以避免在短时间内频繁重试对系统造成压力。
3、死信队列
对于无法正常处理的消息（如超过最大重试次数），MQ通常会将其转移到死信队列（Dead Letter Queue，DLQ）。死信队列是一个特殊的队列，用于存放那些无法正常处理的消息。通过监控死信队列，可以及时发现并处理这些异常消息，从而确保消息系统的可靠性。
消息的重复消费问题如何解决：保证消息的唯一性，保证消息的幂等性
4、监控与报警
为了确保Mq消费者系统的可靠性，还需要实施全面的监控体系。监控内容可以包括消息发送速率、消费延迟、队列长度、服务器健康状况等关键指标。一旦发现异常指标，应立即触发报警机制，以便及时介入处理并防止问题扩大。
这一机制确保了消息在处理过程中的可靠性，防止了消息因处理失败而丢失或未被正确处理的情况。
5、容错与恢复
在分布式系统中，节点故障是不可避免的。为了确保Mq消费者系统的可靠性，需要采取容错与恢复措施。例如，可以通过集群部署、主备节点切换等方式来确保系统的高可用性。当某个节点发生故障时，其他节点可以接管其工作，从而确保消息的正常处理。