接 口 ， 处 理 回 调 ， 在 调 endTransactionOneway 向 broker 发送请求更新事物消息的最终状态 无 Prepared 消息，且遍历完，则终止扫描这个文件的定时任务 2.2.5 事物消息的 load&recover TransactionStateService.load ()事物状态服务加载， 加载只是建立文件映射 redoLog 队列恢复，加载本地 变量 构建 offsetStore 消费进度存储对象 启动消费消息服务 向 mqClientFactory 注册本消费者 启动 client 端远程通信 启动定时任务 定时获取 nameserver 地址 定时从 nameserver 获取 topic 路由信息 定时清理下线的 borker 定时向所有 broker entlyServic的submitConsumeRequest方法构建ConsumeRequest 任务提交到线程池。 长轮询向 broker 拉取消息是批量拉取的， 默认设置批量的值为 pullBatchSize = 32， 可配置 消费端 consumer 构建一个消费消息任务 ConsumeRequest 消费一批消息的个数是 可配置的 consumeMessageBatchMaxSize

提交一个文档被接受也同样可以，难的是持续贡献，最终被开源项目的 PMC 认为对该项目 有着突出贡献。 我比较“苦逼”，在带娃方面我的资源只有我老婆，父母在老家无法分身，故下班后我 没有连续的空闲时间专心投入一项任务中，而开源最需要的是精益求精，不只是需要完成功 能，而是要编写结构优良的代码，设计所占据的时间比代码开发时间要多的多，故我个人认 为我暂时不方便走代码贡献这条道路。但我零碎时间还是充足的，故现阶段我会好好利用这 15 > 1.1 RocketMQ 核心概念扫盲篇 上述整个过程无需应用程序干预，由 RocketMQ 完成。大概的做法就是将将原先分配 给自己但这次不属于的队列进行丢弃，新分配的队列则创建新的拉取任务。 3. 消费进度 消费者消费一条消息后需要记录消费的位置，这样在消费端重启的时候，继续从上一次 消费的位点开始进行处理新的消息。在 RocketMQ 中，消息消费位点的存储是以消费组为 单位的。 Broker 服务端就会存在主题的路由信息。 在 Broker 端的 topic 配置管理器中存在的路由信息，一会向 Nameserver 发送心跳 包，汇报到 Nameserver，另一方面会有一个定时任务，定时存储在 broker 端，具体路 径为${ROCKET_HOME}/store/config/topics.json 中，这样在 Broker 关闭后再重启， 并不会丢失路由信息。 广大

容量不足，Kafka 分区迁移时，会导致网络风暴，耗时极长 问题重点 • 在主节点宕机时，备节点要有自动切换为主的能力 • 容量调整时，不能产生数据迁移，且要在秒级完成 固定分区使用场景 • 任务计算过程中，会将同一个业务类型的数据发到同一个队列 • Binlog 等数据同步过程中，需要保证严格顺序 RAFT 存储支持：自动主从切换，强一致性保证 逻辑队列：秒级无损弹性扩缩，无数据复制，流量精准调度