听得到微笑的博客

在生产端，客户端通过四层的 TCP 协议和 NameServer 建立连接，通过 Remoting 协议从NameServer 获取到集群的元数据信息。根据元数据信息，和对应的 Broker 的建立 TCP 连接。如果客户端指定了目标 Topic，消息则先经过消息分区分配，然后才将数据发送到Broker 中。因为 Remoting 也没有支持 Batch 的协议，所以数据会直接发送到对应的Broker，可以使用单向发送、同步发送、异步发送三种发送形式。

消息消费以组的模式开展，一个消费组可以包含多个消费者，每个消费组可以订阅多个主题，消费组之间有集群模式和广播模式两种消费模式。集群模式是当前主题下的同一条消息只允许被其中一个消费者消费。广播模式是当前主题下的同一条消息将被集群内的所有消费者消费一次。消息服务器与消费者之间的消息传送也有两种方式：推模式和拉模式。所谓的拉模式，是消费端主动发起拉取消息的请求，而推模式是消息到达消息服务器后，再推送给消息消费者。RocketMQ消息推模式基于拉模式实现，在拉模式上包装一层，一个拉取任务完成后开始下一个拉取任务。

Raft 协议主要包含两个部分：Leader选举和日志复制。前面我们在 Raft协议深度解析：RocketMQ中的自动Leader选举与故障转移 一文中已经详细介绍了DLedger如何实现Leader选举的，而本文主要聚焦于Leader选举完成后的日志复制的过程。说起日志的复制，就必须要从日志存储实现说起，它约束着Raft每一个结点如何存储数据。下面先介绍一次Raft存储的核心实现类：DLedgerStore：存储抽象类，该类有如下核心抽象方法：DLedgerMemoryStore：DLedger基于内存实

在分布式系统应用中，高可用、一致性是经常面临的问题，针对不同的应用场景，我们会选择不同的架构方式，比如master-slave、基于ZooKeeper选主。随着时间的推移，出现了基于Raft算法自动选主的方式，Raft 是在 Paxos 的基础上，做了一些简化和限制，大大简化了算法的复杂度。Raft协议是目前分布式领域一个非常重要的一致性协议，RocketMQ 的主从切换机制也是介于Raft协议实现的。Raft 协议主要包含两个部分：Leader选举和日志复制。

RocketMQ支持两种方式的消息过滤：TAG/SQLTAG 过滤分两个阶段完成：第一阶段：broker率先根据tag的hashcode完成过滤第二阶段：consumer根据tag值完成最后的过滤SQL过滤只能在Broker中完成。

RocketMQ存储的文件主要包括CommitLog文件、ConsumeQueue文件、Index文件。RocketMQ将所有topic的消息存储在同一个文件中，确保消息发送时按顺序写文件，尽最大的能力确保消息发送的高性能与高吞吐量。因为消息中间件一般是基于消息主题的订阅机制，所以给按照消息主题检索消息带来了极大的不便。为了提高消息消费的效率，RocketMQ引入了ConsumeQueue消息消费队列文件，每个topic包含多个消息消

半事务消息：指的是发送至broker但是还没被commit的消息，在半事务消息被确认之前都是无法被消费者消费的。消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，broker 通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（commit 或是 rollback），该询问过程即消息回查。

本文将讲解如何在IDEA中导入 RocketMQ 源码，并运行 Broker 和 NameServer，编写一个消息发送与消息消费的示例。

主从同步这个概念相信大家在平时的工作中，多少都会听到。其目的主要是用于做一备份类操作，以及一些读写分离场景。比如我们常用的关系型数据库mysql，就有主从同步功能在。主从同步，就是将主服务器上的数据同步到从服务器上，也就是相当于新增了一个副本。而具体的主从同步的实现也各有千秋，如mysql中通过binlog实现主从同步，es中通过translog实现主从同步，redis中通过aof实现主从同步。那么，rocketmq又是如何实现的主从同步呢？另外，主从同步需要考虑的问题是哪些呢？数据同步的及时性？