jike11231的博客

某版本需求，代码处理逻辑错误，导致配置新增服务范围扩大，造成消息成百倍增长，突增的消息通道部分拥堵。新增的服务会不断重试并重推消息，造成更严重的任务拥堵，无法及时消费，数据库压力增大，SQL执行变慢，导致核心业务受阻。

Slf4j// 声明业务交换机@Bean// 声明死信交换机@Bean// 声明业务队列@Bean// 设置业务队列的死信交换机// 声明死信队列@Bean// 将业务队列绑定到业务交换机@Bean// 将死信队列绑定到死信交换机@Bean。

RabbitMQ提供了消息确认机制，即生产者在发送消息后，可以等待RabbitMQ服务器返回确认信息，以确保消息已经被正确地接收和处理。在发布消息时，可以设置消息的持久化标志，这样消息就会被写入磁盘中，而不是仅仅保存在内存中。可以通过设置重试次数和重试时间间隔来控制消息重试的行为。综上所述，RabbitMQ通过持久化、确认、事务和重试等机制来保证消息的可靠性，从而解决消息丢失的问题。可以看到由于接口中第1，4，5条消息会正常发送，所以在consumer已经进行了正常消费，并且针对第5条进行了业务重试。

配置死信交换机和死信队列，对于那些重复投递依然无法正确处理的消息，可以转移到死信队列，并设置相应的重试策略及最大重试次数，超过限制则记录日志、报警或手动介入处理。如果在执行消费的过程中，出错了（抛出Exception），则记录消费失败的状态，MQ会再次尝试去进行消费。这里是为了避免在消息开始消费后，RabbitMq宕机了，此时MQ并不知道这个消息最终有没有消费完成，因此重启MQ之后，MQ会重新消费这条消息。可以看到消费者服务，消费完第2个消息后，由于RabbitMQ宕机，本地服务报错，无法消费第3个消息。

当消息写入到 Broker 后，不会立刻被消费者消费，需要等待指定的时长后才可被消费处理的消息，称为延时消息。

分布式事务解决方案有许多比如二阶段提交、TCC、最大努力通知、Saga事务等，本文介绍本地消息表+MQ这种方式解决分布式事务消息最总一致性问题。目前利用本地消息表+MQ方案实现最终消息一致性的比较多，它的核心思想是，将分布式事务拆分成本地事务进行处理，不同事务之间通过消息表和MQ通信，最后通过定时任务扫描失败的数据进行重试，当在有效重试次数限制内，再次重试回调失败的数据，最终实现消息重复发送，达到一致性。本地消息表实现最终一致性。将rocketmq-dashboard导入到idea中，在idea编译启动。

本项目是参考网上资料，整理开发而成，项目代码中加入了自己的理解和实现。​基于SpringBoot框架开发，实现的功能主要是登录、商品列表、商品详情、秒杀商品，订单详情等功能。在系统业务处理中，使用到分布式session维持会话、Redis预减库存降低数据库访问压力，消息队列异步下单（削峰）、客户端轮询结果、接口限流防刷等技术。

一、为什么使用消息队列？其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。1.1 解耦看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据

一、消息推送到接收的流程图首先先介绍一个简单的一个消息推送到接收的流程，提供一个简单的图：黄色的圈圈就是我们的消息推送服务，将消息推送到 中间方框里面也就是 rabbitMq的服务器，然后经过服务器里面的交换机、队列等各种关系（后面会详细讲）将数据处理入列后，最终右边的蓝色圈圈消费者获取对应监听的消息。常用的交换机有以下三种，因为消费者是从队列获取信息的，队列是绑定交换机的（一般），所以对应的消息推送/接收模式也会有以下几种：1.Direct Exchange直连型交换机，根据消息携带的路由键将

一、RabbitMQ的基础概念BrokerBroker：简单来说就是消息队列服务器实体。中文意思：中间件。接受客户端连接，实现AMQP消息队列和路由功能的进程。一个broker里可以开设多个vhost，用作不同用户的权限分离。RabbitMQ官网解释A RabbitMQ broker is a logical grouping of one or several Erlangnodes, each running the RabbitMQ application and sharing us