上次跟大家分享的文章「Kafka Producer 异步发送消息居然也会阻塞？」中提到了缓冲池，后面再经过一番阅读源码后，发现了这个缓冲池设计的很棒，被它的设计思想优雅到了，所以忍不住跟大家继续分享一波。

在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader，导致某些消息发送到该分区时，会报如下 no leader 的错误信息：

之前发表了一篇关于重平衡的文章：「Kafka 重平衡机制」，里面有说到 RocketMQ 重平衡机制是每隔 20s 从任意一个 Broker 节点获取消费组的消费 ID 以及订阅信息，再根据这些订阅信息进行分配，然后将分配到的信息封装成 pullRequest 对象 pull 到 pullRequestQueue 队列中，拉取线程唤醒后执行拉取任务，流程图如下：

当集群中有新成员加入，或者某些主题增加了分区之后，消费者是怎么进行重新分配消费的？这里就涉及到重平衡（Rebalance）的概念，下面我就给大家讲解一下什么是 Kafka 重平衡机制，我尽量做到图文并茂通俗易懂。

还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗？经过调整 max.request.size 的大小之后，又报了了如下异常：

其中，如果是广播模式消费，消息的消费进度是保存到本地，如果是集群消费模式，消息的消费进度则是保存到 Broker，但无论是保存到本地，还是保存到 Broker，消费者都会在本地留一份缓存，我们暂且看看集群消费模式下，消息消费进度的缓存是如何保存的：

一般来说，选择主从备份实现高可用的架构中，都会具备读写分离机制，比如 MySql 读写分离，客户端可以向主从服务器读取数据，但客户写数据只能通过主服务器。

之前写了一篇关于 RocketMQ 队列与 Kafka 分区副本的区别文章，里面提到了 RocketMQ 的消息冗余主要是通过主备同步机制实现的，这跟 Kafka 分区副本的 Leader-Follower 模型不同，HA（High Available) 指的是高可用性，而 RocketMQ 的HA机制是通过主备同步实现消息的高可用。

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 前段时间有个朋友向我提了一个问题，他说在搭建 RocketMQ 集群过程中遇到了关于消费订阅的问题，具体问题如下： 然后他发了报错的日志给我看： {代码...} 我第一时间在源码里找到了报错的位置： org.apache.rocketmq.br...