二狗家有矿

0、彩蛋先来看看大佬们的代码是怎么写的：package org.apache.rocketmq.common.protocol.header;/** * Use short variable name to speed up FastJson deserialization process. */public class SendMessageRequestHeaderV2 implements CommandCustomHeader { @CFNotNull ...

一、架构图以及角色1、架构图2、角色2.1、Broker 理解成RocketMQ本身 broker主要用于producer和consumer接收和发送消息 broker会定时向nameserver提交自己的信息 是消息中间件的消息存储、转发服务器 每个Broker节点，在启动时，都会遍历NameServer列表，与每个NameServer建立长连接，注册自己的信息，之后定时上报 2.2、Nameserver 理解成zookeepe...

一、Java API说明：RocketMQ服务端版本为目前最新版：4.7.0 Java客户端版本采取的目前最新版：4.7.0 pom如下<dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.7.0</version></de

在实际使用RocketMQ的时候我们并不能保证每次发送的消息都刚好能被消费者一次性正常消费成功， 可能会存在需要多次消费才能成功或者一直消费失败的情况，Broker该如何处理呢？1.消息消费端的确认机制RocketMQ提供了ack机制（默认是手动ack），以保证消息能够被正常消费。为了保证消息肯定消费成功，只有使用方明确表示消费成功，RocketMQ才会认为消息消费成功，然后删除消息。中途断电，抛出异常等都不会认为成功DefaultMQPushConsumer consumer = new D

1.消息发送模式1.1 同步发送同步消息发送模式就是说消息发送出去后，producer会等到broker回应后才能继续发送下一个消息DefaultMQProducer producer = new DefaultMQProducer("my_producer_group");producer.send(message); // 同步发送返回的SendResult有四种状态：SEND OK（成功），FLUSH_DISK_TIMEOUT（刷盘超时），FLUSH_SLAVE_TIM...

1.RocketMQ消费模型RocketMQ提供了两种消息消费模型，一种是pull主动拉取，另一种是push被动接收。实际上 RocketMQ都是pull模式，而push只是在pull模式上做了一层封装 RocketMQ是基于长轮训来实现消息的pull pull到消息以后触发业务消费者注册的call back2.消费规则我们在【RocketMQ】原理分析：Broker集群模式、队列分区介绍了RocketMQ的多住多从集群模式和通过多个消息队列实现分区。所以如果有一个consumer...

由于分布式消息队列对于可靠性的要求比较高，所以需要保证生产者将消息发送到broker之后，保证消息是不出现丢失的，因此消息队列就少不了对于可靠性存储的要求。从主流的几种MQ消息队列采用的存储方式来看，主要会有三种分布式KV存储， 这种存储方式对于消息读写能力要求不高的情况可以使用 比如ActiveMQ中采用的levelDB、Redis， 文件系统存储， 这种方案适合对于有高吞吐量要求的消息中间件，因为消息刷盘是一种高效率，高可靠、高性能的持久化方式，除非磁盘出现故障，否则一般是不...

1.Broker集群模式（宏观）RocketMQ天生对集群的支持非常友好，天然支持高可用，它可以支持多主多从的部署架构，这也是和kafka大区别之一（PS：Kafka的分区副本可以看成一主多从）。那为什么要将这么多broker组织成多主多从，而不是采用一主多从然后主节点down机后再选举啊？因为。。。RocketMQ中并没有master选举功能，在RocketMQ集群中，1台机器只能要么是Master，要么是Slave，这个在初始的机器配置里面，就定死了。不会像kafka那样存在master动态

RocketMQ和其他消息中间件最大的一个区别是支持了事务消息，这也是分布式事务里面的基于消息的最终一致性方案。1.事务消息是什么？事务消息：具有事务特性的消息，即Producer发送到broker后，该消息可以回滚或者提交（提交后Consumer才可见）。2.事务消息有什么用？RocketMQ官方示例：用户A发起订单，支付100块钱操作完成后，能得到100积分，账户服务和会员服务是两个独立的微服务模块，有各自的数据库，按照上文提及的问题可能性，将会出现这些情况： 如果先扣款，再...

1.消息中间件的设计可以先从基本的需求开始思考 基本的是要能支持消息的发送和接收，需要涉及到网络通信就一定会涉及到NIO 消息中心的消息存储（持久化/非持久化） 消息的序列化和反序列化 是否跨语言 消息的确认机制，如何避免消息重发 高级功能 消息的有序性 是否支持事务消息 消息收发的性能，对高并发大数据量的支持 是否支持集群 消息的可靠性存储 是否支持多协议2.MQ消息存储选择从主流的几种MQ消息队列采用的存储方式来看，主要会有三种分布式KV存储，比如...

一、事务消息的由来1、案例引用官方的购物案例：小明购买一个100元的东西，账户扣款100元的同时需要保证在下游的积分系统给小明这个账号增加100积分。账号系统和积分系统是两个独立是系统，一个要减少100元，一个要增加100积分。如下图：2、问题账号服务扣款成功了，通知积分系统也成功了，但是积分增加的时候失败了，数据不一致了。 账号服务扣款成功了，但是通知积分系统失败了，所以积分不会增加，数据不一致了。3、方案RocketMQ针对第一个问题解决方案是：如果消费失败了，是会自动重试的

一、顺序消息解释1、概述RocketMQ的消息是存储到Topic的queue里面的，queue本身是FIFO（First Int First Out）先进先出队列。所以单个queue是可以保证有序性的。但是问题是1个topic有N个queue，作者这么设计的好处也很明显，天然支持集群和负载均衡的特性，将海量数据均匀分配到各个queue上，你发了10条消息到同一个topic上，这10条消息会自动分散在topic下的所有queue中，所以消费的时候不一定是先消费哪个queue，后消费哪个queue，这就

篇幅不是每一行代码都进行解析，没意义。冗余的文字你看着烦我写着也闹心，只剖析核心流程以及原理。一、Demoimport org.apache.rocketmq.client.producer.DefaultMQProducer;import org.apache.rocketmq.client.producer.SendResult;import org.apache.rocketmq.common.message.Message;/** * Description: * ...

一、说明分为两种，一种是直接发消息，client内部有选择queue的算法，不允许外界改变。还有一种是可以自定义queue的选择算法（内置了三种算法，不喜欢的话可以自定义算法实现）。public class org.apache.rocketmq.client.producer.DefaultMQProducer { // 只发送消息，queue的选择由默认的算法来实现 @Override public SendResult send(Collection<Messa

一、原理1、消息存在哪了？消息持久化的地方其实是磁盘上，在如下目录里的commitlog文件夹里。/root/store/commitlog源码如下：// {@link org.apache.rocketmq.store.config.MessageStoreConfig}// 数据存储根目录private String storePathRootDir = System.getProperty("user.home") + File.separator + "store";

面试官常常喜欢问：Rocket MQ 怎么保证的消息不丢失？我想说：就这？我笑了。一、消息发送过程我们将消息流程分为如下三大部分，每一部分都有可能会丢失数据。生产阶段：Producer通过网络将消息发送给Broker，这个发送可能会发生丢失，比如网络延迟不可达等。 存储阶段：Broker肯定是先把消息放到内存的，然后根据刷盘策略持久化到硬盘中，刚收到Producer的消息，再内存中了，但是异常宕机了，导致消息丢失。 消费阶段：消费失败了其实也是消息丢失的一种变体吧。二、P...

一、问题复现1、描述两个一样的Consumer Group的Consumer订阅同一个Topic，但是是不同的tag，Consumer1订阅Topic的tag1，Consumer2订阅Topic的tag2，然后分别启动。这时候往Topic的tag1里发送10条数据，Topic的tag2里发送10条。目测应该是Consumer1和Consumer2分别收到对应的10条消息。结果却是只有Consumer2收到了消息，而且只收到了4-6条消息，不固定。2、代码2.1、Consumerpubl

一、问题描述面试官：RocketMQ的Consumer是如何做的负载均衡？比如：5个Consumer进程同时消费一个Topic，这个Topic只有4个queue会出现啥情况？反之Consumer数量小于queue的数据是啥情况？应聘者：一脸懵逼。二、源码剖析1、RebalancePushImplpublic class RebalancePushImpl extends RebalanceImpl { public RebalancePushImpl(String consum

一、为什么要集群单点存在单点故障问题 集群可以分担压力，提高QPS 主从可以保证消息可靠性，比如只有M没S。M磁盘坏了，那未被消费的消息都丢了。而S可以作为备份。二、单M模式1、特点只有一个Master节点，所以单点故障是致命缺点。 优点：配置简单，方便部署。 缺点：单点故障，一旦Broker重启或者直接宕机了，那会导致整个服务不可用。2、图解三、多M模式1、特点一个集群无Slave节点，全是Master节点。 优点：配置相对不复杂，单个M宕机或者重启对业务系统无感

0、彩蛋先来看看大佬们的代码是怎么写的：package org.apache.rocketmq.common.protocol.header;/** * Use short variable name to speed up FastJson deserialization process. */public class SendMessageRequestHeaderV2 implements CommandCustomHeader { @CFNotNull priva