【RockeMQ】第2节｜RocketMQ快速实战以及核⼼概念详解（二）

升级Dledger高可用集群

一、主从架构的不足与Dledger的定位

主从架构缺陷
- 数据备份依赖Slave节点，但无自动故障转移能力，Master宕机后需人工切换，期间消息可能无法读取。
- Slave仅存储数据，无法主动升级为Master响应请求，集群高可用性不足。
Dledger的核心价值
- 基于Raft协议实现自动选举和数据强一致性，支持Leader节点故障时自动切换，保障服务连续性。
- 解决传统主从架构的“单点故障”和“脑裂问题”，提升集群可靠性。

二、Dledger集群架构与原理

角色分工
- Leader：唯一主节点，处理客户端请求，通过日志复制同步数据到Follower。
- Follower：从节点，接收并持久化Leader数据，参与选举。
Raft协议关键机制
- 选举机制：候选人需获得超过半数节点投票才能成为Leader，确保集群唯一主节点。
- 任期（Term）：每个选举周期生成唯一任期号，避免旧Leader干扰新选举。
- 心跳机制：Leader定期发送心跳维持统治，超时则触发重新选举。
- 日志复制：Leader数据需多数Follower确认后才提交，保障强一致性。
脑裂问题解决
- 通过Raft协议的选举规则和多数确认机制，确保同一时刻仅存在一个有效Leader，避免多主冲突。

三、Dledger集群搭建步骤（以3节点为例）

环境配置
- 3台服务器（worker1、worker2、worker3），已部署NameServer集群，修改/etc/hosts绑定主机名。
- 每个节点创建独立存储目录（如/app/rocketmq/storeDledger），避免数据混淆。
核心配置文件
- 在conf/dledger/broker.conf中配置：

brokerClusterName=RaftCluster       # 集群名（统一标识）  
brokerName=RaftNode00              # 节点组名（同一集群内一致）  
listenPort=30911                   # 服务端口（避免与主从架构冲突）  
namesrvAddr=worker1:9876;worker2:9876;worker3:9876  # NameServer地址  
enableDLegerCommitLog=true         # 启用Dledger功能  
dLegerGroup=RaftNode00             # Dledger组名（与brokerName一致）  
dLegerPeers=n0-worker1:40911;n1-worker2:40911;n2-worker3:40911  # 节点列表（格式：id-主机:端口）  
dLegerSelfId=n0                    # 当前节点ID（需在dLegerPeers中唯一，worker1设n0，worker2设n1，worker3设n2）

启动与验证
- 各节点执行命令启动Broker：

nohup bin/mqbroker -c conf/dledger/broker.conf &

- 通过Dashboard或mqadmin命令查看集群状态，确认1个Leader和2个Follower。
- 模拟故障：停止Leader节点，观察剩余节点是否自动选举新Leader（需保证≥2节点存活）。

四、Dledger与主从架构对比

维度	主从架构	Dledger集群
故障恢复	人工切换，服务中断	自动选举Leader，秒级恢复
数据一致性	异步复制（可能丢失少量数据）	强一致性（多数节点确认）
脑裂风险	存在	彻底避免（Raft协议保障）
运维成本	高（需手动管理主从状态）	低（自动化管理）
性能影响	低	中（选举和日志复制开销）

五、注意事项与最佳实践

节点数量建议
- 部署奇数个节点（如3/5个），容错能力为(n-1)/2（3节点可容忍1个故障，5节点可容忍2个故障）。
性能调优
- 调整sendMessageThreadPoolNums为服务器CPU核心数，提升消息处理吞吐量。
- 启用异步刷盘（flushDiskType=ASYNC_FLUSH）降低延迟，但需权衡数据可靠性。
生产环境建议
- 关闭自动创建Topic（autoCreateTopicEnable=false），避免资源滥用。
- 结合Prometheus+Grafana监控Leader选举耗时、消息复制延迟等指标。

总结RocketMQ的运行架构

一、核心组件与功能

NameServer
- 定位：集群的“大脑”，提供轻量级路由管理，不存储状态，节点间相互独立。
- 功能：
  - 接收Broker注册信息，维护Topic与Broker的路由关系。
  - 为Producer和Consumer提供实时路由查询服务。
Broker
- 定位：核心数据节点，负责消息存储、转发与查询，类似“硬盘”角色。
- 分类：
  - Master：处理读写请求，支持数据同步到Slave。
  - Slave：备份Master数据，故障时可切换为只读节点（主从架构）或自动升级为Leader（Dledger集群）。
Client（生产者/消费者）
- 定位：集群的“输入输出设备”，通过NameServer获取路由，与Broker直接交互。
- 关键逻辑：
  - Producer：按负载均衡策略将消息发送到Topic的多个MessageQueue。
  - Consumer：通过Pull或Push模式从MessageQueue拉取消息，支持广播模式和集群模式。

二、消息路由与存储机制

Topic与MessageQueue
- Topic：逻辑消息分类，数据分散存储在多个MessageQueue中（默认8个队列）。
- MessageQueue：物理存储单元，具有FIFO特性，消息按offset顺序存储。
路由流程
- Producer发送消息时，通过NameServer获取Topic对应的Broker列表，按轮询等策略选择MessageQueue。
- Consumer消费时，根据分配策略（如平均分配）绑定MessageQueue，维护本地消费进度（offset）。

三、集群模式对比

模式	主从架构	Dledger集群
路由更新	Broker主动向NameServer注册	同上
高可用性	依赖人工切换	自动故障转移
适用场景	中小规模业务、非核心场景	大规模集群、金融级高可靠场景

理解RocketMQ的消息模型

一、核心概念

消息（Message）
- 由Topic（主题）、Tag（标签）、Body（内容）组成，支持属性扩展（如事务ID、延迟时间）。
消费者组（Consumer Group）
- 同一组内消费者协同消费，支持负载均衡（集群模式）或独立消费（广播模式）。
- 消费进度以组为单位存储，不同组可独立消费同一Topic。

二、消息投递模式

集群模式（默认）
- 多个消费者实例分摊消费压力，每条消息仅被组内一个实例处理。
- 应用场景：订单处理、实时数据分析。
广播模式
- 每条消息被组内所有消费者实例消费，进度独立管理。
- 应用场景：配置更新通知、日志广播。

三、消息存储与消费流程

存储流程
- Producer发送消息至Broker的MessageQueue，持久化到CommitLog文件。
- Broker定期将CommitLog数据刷盘，并构建索引文件（ConsumeQueue、IndexFile）加速查询。
消费流程
- Consumer从NameServer获取Topic路由，拉取MessageQueue中的消息。
- 消费成功后，更新本地offset（集群模式同步到Broker，广播模式存储于本地文件）。

四、与Kafka的对比

特性	RocketMQ	Kafka
消息顺序	单个MessageQueue内有序	单个Partition内有序
事务支持	原生支持（两阶段提交）	需外部系统协调
多语言客户端	官方支持Java、C++、Go等	依赖社区实现
管理工具	提供Dashboard可视化界面	依赖命令行或开源工具（如Kafka UI）

章节总结

一、核心知识回顾

快速实战
- 掌握RocketMQ单机、主从、Dledger集群的搭建流程，调整JVM参数适应资源限制。
- 使用命令行工具（tools.sh）和Java API实现消息收发，结合Dashboard监控集群状态。
架构设计
- NameServer无状态集群提供路由服务，Broker通过主从或Dledger实现高可用。
- 消息模型基于Topic和MessageQueue，支持灵活的消费模式与负载均衡策略。
核心特性
- 事务消息、延迟队列、死信队列等功能满足复杂业务需求（后续章节深入）。
- Dledger集群通过Raft协议解决传统主从架构的高可用短板，适合金融级场景。

二、延伸学习建议

对比分析
- 结合Kafka和RabbitMQ，理解不同MQ在吞吐量、可靠性、功能丰富度上的差异。
生产实践
- 尝试在Docker/Kubernetes中部署RocketMQ集群，实践资源编排与弹性扩缩容。
- 实现基于RocketMQ的分布式事务（如订单支付场景），结合本地事务表保证最终一致性。
源码阅读
- 从org.apache.rocketmq.broker包入手，理解Broker启动流程与消息存储逻辑。