zhzjn的博客

java项目启动遇到的问题如下主要是以下问题Connection refused: no further information 连接被拒绝rabbitmq的一般的解决办法localhost127.0.0.1端口一致，配置文件未更改，所以端口，ip地址没错查看防火墙看是否关闭了或者防火墙是否放端口号：5672过发现没有问题，但是连接还是被拒绝然后查看进程是否被占用。

首先，我们需要明确的是，无论是否处于高并发场景，确保消息仅被消费一次都是一个核心需求。这一需求的核心在于，我们必须防止消息在传输和消费过程中丢失，同时避免消息被重复消费。接下来，我们将深入剖析消息从生产到消费的整个链路，并识别出可能导致消息丢失或重复消费的环节。生产者发送消息至消息队列环节是确保消息传递完整性的关键一步。为了保证消息不丢失，需要采取一系列措施，并了解可能导致消息丢失的原因。

在前几篇文章中，我们详细的介绍了RabbitMQ 的内部架构和使用操作，和SpringBoot 整合 RabbitMQ 实现流量消峰的实践方式，以及RabbitMQ 的高可用架构。再次回顾一下当时提过的问题，为何项目中要引用 MQ 消息中间件？我们知道，在电商平台中常见的用户下单，会经历以下几个流程。

只需要让一个消息队列只对应一个消费者即可。

RocketMQ 是一个分布式消息中间件，它包含四个主要组件：NameServer、Broker 、Producer和Consumer。NameServer：（带头大哥NameServer类似于轻量级的服务注册与发现中心，扮演着路由管理的角色。它负责维护 Broker 注册的 Topic 信息、队列信息以及 Broker 的地址列表等路由数据。生产者和消费者都需要连接 NameServer 获取路由信息，从而得知应该向哪个 Broker 发送或订阅消息。Broker：（小弟-干活的）

https://github.com/alibaba/canalCanal 主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费，工作原理如下：Canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 Canal )Canal 解析 binary log 对象(原始为 byte 流)可以用于以下业务场景：数

现在微服务开发中为了满足限流消峰、减少系统之间的耦合等实际业务的需要，于是系统中往往会引入了MQ，加入了MQ之后如何保证消费者的消费幂等性便是需要解决的问题了。幂等性是数学上的一个概念，在我们开发中可以理解成就是多次执行某个方法并且得到结果是一样的，那么我们就认为这个过程就是幂等性。如下就是一些常见的幂等性的案例：查询是具备天然的幂等性（不考虑数据更新/删除的情况下，多次查询始终是一个结果）。如上所示的更新/删除都是具备幂等性的，无论这个更新执行多少次，最终的结果都是一样的。

消费者在接收到消息后，默认情况下RabbitMQ会自动确认消息（autoAck=true）。当publisher-confirm-type设置为CORRELATED时，RabbitMQ会向生产者发送确认或否定响应，确认消息已到达交换机，但不保证消息已被路由到至少一个队列中。： Publisher Return机制用于当消息无法按照路由键规则路由到任何队列时，或者由于其他原因（例如队列满、消息过大等）而被交换机拒绝时，RabbitMQ将消息返回给生产者。2.只要有一个队列接受到消息了，它就认为成功.

下单之后，给10分钟时间进行支付，如果10分钟后，没有支付，订单取消。（可以使用队列的ttl，因为所有的消息都是一样的停留时长10分钟）定时发布文章（要求4月1号凌晨发布）小张 8：00 编辑了一篇文章，目前状态为草稿，发布到队列该消息在队列停留 16个小时，消费者拿到消息后，更改该文章的状态为发布即可。小芳 13：00 编辑了一篇文章，目前状态为草稿，发布到队列该消息在队列停留 11个小时，消费者拿到消息后，更改该文章的状态为发布即可。预约餐厅，提前半个小时发短信通知用户。A包间 -> 13:00。

在 RabbitMQ 中充当主角的就是消息，在不同场景下，消息会有不同地表现。死信就是消息在特定场景下的一种表现形式，这些场景包括：1. 消息被拒绝访问，即消费者返回basicNack的信号时 或者拒绝2. 消费者发生异常，超过重试次数。其实spring框架调用的就是 basicNack3. 消息的Expiration过期时长或队列TTL过期时间。.ttl(20*1000) 进入的是 先进业务队列的数据4. 消息队列达到最大容量 .maxLength(5)

RabbitMQ 中的消息应答模式主要包括两种：自动应答（Automatic Acknowledgement）和手动应答（Manual Acknowledgement）。不在乎消费者对消息处理是否成功，都会告诉队列删除消息。如果处理消息失败，实现自动补偿（队列投递过去 重新处理）。在手动应答模式下，消费者在接收到消息后并不会立即向RabbitMQ确认消息已处理完毕。消费者需要显式调用basicAck方法来确认消息处理完成，RabbitMQ只有在接收到消费者的确认后才会将消息从队列中删除。

.SpringBoot整合RabbitMQ

首先先介绍一个简单的一个消息推送到接收的流程，提供一个简单的图黄色的圈圈就是我们的消息推送服务，将消息推送到 中间方框里面也就是 rabbitMq的服务器，然后经过服务器里面的交换机、队列等各种关系（后面会详细讲）将数据处理入列后，最终右边的蓝色圈圈消费者获取对应监听的消息。

MQ全称 Message Queue（消息队列），是在消息的传输过程中保存消息的。多用于分布式系统之间进行通信，主要功能。