@TOC根据 raft 协议可知，当整个集群完成 Leader 选主后，集群中的主节点就可以接受客户端的请求，而集群中的从节点只负责从主节点同步数据，而不会处理读写请求，与M-S结构的读写分离有着巨大的区别。

集群信息如下：例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示：当前的消费者信息：broker 的配置信息如下：

@TOCRocketMQ DLedger 的存储实现思路与 RocketMQ 的存储实现思路相似，本文就不再从源码角度详细剖析其实现，只是点出其实现关键点。我们不妨简单回顾一下 CommitLog 文件、ConsumeQueue 文件设计思想。

Raft协议是分布式领域解决一致性的又一著名协议，主要包含Leader选举、日志复制两个部分。 温馨提示：本文根据raft官方给出的raft动画进行学习，其动画展示地址：[链接] @TOC 1、Leader选举 1.1 一轮投票中，只有一个节点发起投票的情况 Raft协议中节点有3种状态（角色）： Follower 跟随者。 Candidate 候选者。 Leader...

温馨提示：《RocketMQ技术内幕》作者倾力打造的全新专栏：RocketMQ 多副本(主从切换)：1、《RocketMQ 多副本前置篇：初探raft协议》 本文将按照《RocketMQ 多副本前置篇：初探raft协议》的思路来学习RocketMQ选主逻辑。首先先回顾一下关于Leader的一些思考： 节点状态 需要引入3种节点状态：Follower(跟随者)、Candidate...

Raft协议是分布式领域解决一致性的又一著名协议，主要包含Leader选举、日志复制两个部分。 温馨提示：本文根据raft官方给出的raft动画进行学习，其动画展示地址：[链接] @TOC 1、Leader选举 1.1 一轮投票中，只有一个节点发起投票的情况 Raft协议中节点有3种状态（角色）： Follower 跟随者。 Candidate 候选者。 Leader...

首先翻阅DefaultMQPushConsumer的API时，setConsumeFromWhere(ConsumeFromWhere consumeFromWhere)API映入眼帘，从字面意思来看是设置消费者从哪里开始消费，正是解开该问题的”钥匙“。ConsumeFromWhere枚举类图如下：