zhiyikeji的博客

顺序消息是消息队列 RocketMQ 提供的一种高级消息类型。对于一个指定的Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费。即先发送的消息先消费，后发送的消息后消费。顺序消息在发送、存储和投递的处理过程中，强调多条消息间的先后顺序关系。RocketMQ 顺序消息的顺序关系通过消息组（MessageGroup）判定和识别，发送顺序消息时需要为每条消息设置归属的消息组，相同消息组的多条消息之间遵循先进先出的顺序关系，不同消息组、无消息组的消息之间不涉及顺序性。

负载均衡在分布式服务里会频繁的出现，其主要是用来在多个资源 (一般是服务器)中分配负载，达到最优化资源使用，避免单台服务器过载。RocketMQ中的负载均衡，指的是如何将消息队列（Message Queue）均匀地分配给消费者组中的各个消费者实例。通过负载均衡机制，可以避免某些消费者实例处理过多消息队列而过载，或者某些实例没有消息可处理，从而提高系统的整体处理能力和资源利用率。

为了优化这个问题，我们可以使用@RocketMQMessageListener注解的returnTopic属性来指定一个返回主题，当消息消费失败时，将消息发送到这个返回主题中。以boot-mq-topic为例，我们实现具体的消费，新增一个对象BootMqConsumer继承我们的CommonConsumer，来实现具体的消费逻辑。中我们已经实现了消费基本生产和消费的实现，但是在真实的开发环境中如果按照这种方式去实现，冗余代码较多，且通过实现。在原始的实现中，我们通过实现。方法来完成消息的消费。

在数学计算或者计算机科学中，幂等性（idempotence）是指相同操作或资源在一次或多次请求中具有同样效果的作用。幂等性在分布式系统设计中具有十分重要的地位。HTTP 幂等方法，是指无论调用多少次都不会有不同结果的 HTTP 方法。不管你调用一次，还是调用一百次，一千次，结果都是相同的。什么意思呢？

里我们已经极大的简化了消息的发送和消费机制，但是对于我们逻辑上的消费失败以及异常情况下的消息重试我们需要自定义重试逻辑，在学习本章前，请保证自己已经完成了上一章的内容，本文便不在赘述。

1.打开，找到下载页面。2.我们直接下载最新版本的压缩包3.解压缩。

在上一章中我们对Rocket的基础知识、特性以及四大核心组件进行了详细的介绍，本章带着大家一起去在项目中具体的进行应用，并设计将其作为一个工具包只提供消息的分发服务和业务模块进行解耦。

RocketMQ 是阿里巴巴开源的分布式消息中间件,现已成为 Apache 软件基金会的顶级项目。支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。它里面有几个区别于标准消息中件间的概念，如Group、Topic、Queue等。系统组成则由Producer、Consumer、Broker、NameServer等组件组成。

在搭建之前，我们需要做一些准备工作，这里我们需要使用 docker 搭建服务，所以需要提前安装 docker。此外，由于 rocketmq 需要部署broker与nameserver，考虑到分开部署比较麻烦，这里将会使用。

我们通过分析消息从生产者发送消息到消费者消费消息的全过程，得出了消息可能丢失的几种场景，并给出了相应的解决方案，如果需要保证消息在整条链路中不丢失，那就需要生产端、mq自身与消费端共同去保障。生产端：对生产的消息进行状态标记，开启confirm机制，依据mq的响应来更新消息状态，使用定时任务重新投递超时的消息，多次投递失败进行报警。mq自身：开启持久化，并在落盘后再进行ack。如果是镜像部署模式，需要在同步到多个副本之后再进行ack。

1.案例背景我们以京东系统为例，用户在购买商品时，通常会选择用京豆抵扣一部分的金额，在这个过程中，交易服务和京豆服务通过 MQ 消息队列进行通信。在下单时，交易服务发送“扣减账户 X 100 个京豆”的消息给 MQ 消息队列，而京豆服务则在消费端消费这条命令，实现真正的扣减操作。在实现以上操作的过程中，我们会遇到哪些问题呢？2.案例分析首先我们需要先知道我们引入 MQ 消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题。系统解耦：用 MQ 消息

文章目录 1.场景描述1.1 场景11.2 场景22.原理3.实战开发3.1 建表3.2 集成mybatis-plus3.3 集成RabbitMq3.3.1 安装mq3.3.2 springBoot集成mq3.4 具体实现3.4.1 mq配置类3.4.2 生产者3.4.3 消费者 1.场景描述消息中间件是分布式系统常用的组件，无论是异步化、解耦、削峰等都有广泛的应用价值。我们通常会认为，消息中间件是一个可靠的组件——这里所谓的可靠是指，只要我把消息成功投递到了消息中间件，消息就不会丢失，即消息肯定会至少

我们在使用rabbitMq控制台进行操作的时候会发现提示以下错误：解决办法也很简单，我是用docker配置的，解决方案如下：进入容器：docker exec -it rabbitmq的镜像id /bin/bashcd到目录/etc/rabbitmq/conf.d/，然后执行以下命令：echo management_agent.disable_metrics_collector = false > management_agent.disable_metrics_collector.con

1.场景描述消息中间件是分布式系统常用的组件，无论是异步化、解耦、削峰等都有广泛的应用价值。我们通常会认为，消息中间件是一个可靠的组件——这里所谓的可靠是指，只要我把消息成功投递到了消息中间件，消息就不会丢失，即消息肯定会至少保证消息能被消费者成功消费一次，这是消息中间件最基本的特性之一，也就是我们常说的“AT LEAST ONCE”，即消息至少会被“成功消费一遍”。1.1 场景1什么意思呢？举个例子：一个消息M发送到了消息中间件，消息投递到了消费程序A，A接受到了消息，然后进行消费，但在消费到一半.