时间仓促，待更新。有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取最新文章。或扫描如下二维码：

在上1篇，我们介绍了kafka server的1个核心组件Controller，今天我们介绍第2个核心组件ReplicaManager。ReplicaManager主要功能是完成消息从leader到其它followers的同步。ReplicaManager核心数据结构假如有1堆的broker: b0, b1, b2, b3, …当前结点为b2；b2有3个partition:t0p0,

对于任何服务器程序来讲，网络框架都是其最基础的部分。在前面我们分析了Producer端的NIO和Network框架，本篇将详细分析服务器端的Network框架。同时对比一下Kafka的1+N+M模型和Tomcat 6的1+N+M模型有什么重要区别。有兴趣朋友可以关注公众号“架构之道与术”， 获取最新文章。或扫描如下二维码：入口 KafkaServer让我们从main函数出发...

我们知道，Kafka是通过ZK的临时节点来监测Broker的死亡的。当一个Broker挂了之后，ZK上面对应的临时节点被删除，同时其他Broker收到通知。那么在RocketMQ中，对应的NameServer是如何判断一个Broker的死亡呢？有兴趣朋友可以关注公众号“架构之道与术”， 获取最新文章。或扫描如下二维码：NameSrv监测Broker的死亡机制之一：监测连...

从本篇开始，我们进入服务器端的源码分析。在正式进入服务器源码分析之前，需要先从宏观上对Kafka的集群管理有一个基本了解。在序列1里面，我们画了Kafka集群的物理架构图，知道所有的broker启动之后，都会连接到Zookeeper上面。那具体来讲，Zookeeper要帮助Kafka完成什么工作呢？集群管理的思路broker的“生“与“死“任何时候，当集群中有1个新的broker加入，或者某个旧的

在上一篇，分析ReplicaManager的同步原理时，提到了DelayedOperationPurgatory，这个部件完成了2个核心功能：1个是check DelayedProduce的complete条件，如果条件满足（也就是所有replica同步消息完成），则调用DelayedOperation的onComplete函数；另1个就是实现“超时”机制。本篇将详细分析其内部结构。Dela

在前面讲了，KafkaConsumer的一个重要部件就是SubscriptionState，这个部件维护了Consumer的消费状态，本篇对其内部结构进行分析。2个offset在前面我们讲了，一个TopicPartition其实有2个offset，一个是当前要消费的offset(poll的时候），一个是消费确认过的offset。public class SubscriptionState {

在上1篇我们提到整个Kafka集群有一个“中央控制器“－Controller，这个Controller从所有brokers中选举出来，当Controller挂了之后，其它brokers再次竞选出新的Controller，本篇将详细介绍这个过程。基本原理整个选举过程是通过zk上的一个临时节点来实现的：/controller节点，其data结构为：核心信息就是记录当前的controller的broke

在Kafka源码分析－序列2中，我们提到了整个Producer client的架构图，如下所示：其它几个组件我们在前面都讲过了，今天讲述最后一个组件RecordAccumulator.Batch发送在以前的kafka client中，每条消息称为 “Message”，而在Java版client中，称之为”Record”，同时又因为有批量发送累积功能，所以称之为RecordAccumulator.R

同Kafka一样，RocketMQ也需要探讨一个问题：如何把一个topic的多个queue分摊给不同的consumer，也就是负载均衡问题。有兴趣朋友可以关注公众号“架构之道与术”， 获取最新文章。或扫描如下二维码：在讨论这个问题之前，我们先看一下Client的整体架构。Producer与Consumer类体系从下图可以看出以下几点：（1）Producer与Consum...