jike11231的博客

配置死信交换机和死信队列，对于那些重复投递依然无法正确处理的消息，可以转移到死信队列，并设置相应的重试策略及最大重试次数，超过限制则记录日志、报警或手动介入处理。如果在执行消费的过程中，出错了（抛出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