kafka——broker

一、消息设计

消息设计过程是一个消息占用内存变小的过程。

kafka的实现方式本质上使用JavaNIO的ByteBuffer来保存消息 ,同时依赖文件系统提供的页缓存机制，而非依靠Java的堆缓存。

ByteBuffer是紧凑的二进制字节结构，不会有JVM内存中对象8字节边界对齐产生padding问题。

消息格式版本V0、V1、V2版本。

V0版本：

CRC32+magic+attribute+keylen+key+valuelen+value

4B+1B+1B+4B+可变+4B+可变

其中keylen=-1，则没有字段key，valuelen=-1，则没有字段value；所以一条kafkaV0版本的消息长度大于等于14B。

V1版本：

V0版本消息格式没有时间信息，kafka删除过期日志只能依靠日志段文件的“最近修改时间”，这个是可以被修改的，V1相比于V0主要加入了时间字段。

CRC32+magic+attribute+timestamp+keylen+key+valuelen+value

4B+1B+1B+8B+4B+可变+4B+可变

一条kafkaV1版本消息长度大于等于22B。

V2版本：与V0,V1版本进行了很多优化，改动很大

提升空间利用率

①V2改用可变长度存储kenlan，valuelen，具体利用zig-zag编码方式0-->0，-1-->1,1-->2，-2-->3实现，将-1存储为1，-1补码为32个1，zig-zag编码前必须4B存储，zig-zag后1B即可存储。节约很大的空间

②V2版本将CRC值从消息层面移入到batch层面，

③V2版本改用可变长度存储timestamp（原来是8B长度），具体存储的是消息时间戳与batch中时间戳的差值

④V2版本将attribute值从消息层面移入到batch层面，

新增部分字段

①新增消息总长度

②新增位移增量，相对于起始位置。

二、集群管理

Kafka是分布式的消息系统，分布式实现主要是依赖ZooKeeper实现的，每当一个broker启动时，就会将自己注册到ZooKeeper下的一个节点。

zkCli.sh -server mcip:port //可查询ZooKeeper中节点

 

/admin：保存管理脚本的输出结果，如删除topic

/brokers：保存Kafka集群中所有信息，包括/brokers/ids保存broker信息的节点，brokers/topics保存主题节点

/cluster : 保存Kafka集群的简要消息，集群Id还有版本号

/config : 保存kafka集群下各种资源定制化配置信息

/controller：保存Kafka controller组件的注册信息，controller负责集群的领导者选举。

/controller_epoch：你保存controller组件的版本号

三、replica与ISR机制

broker中topic-partition-offset表示一条信息的位置，每个partition都有n（设置）个replica，n个replica采用leader-follower模型

①replica-leader=partition-leader

②kafka维护了一个ISR副本集合，ISR中的所有副本都与leader副本保持同步状态，leader副本也包含在内，

③ISR中有N个副本，可以忍受N-1个副本崩溃而不丢失已提交的消息

④leader选举在ISR中产生。

四、日志存储

kafka日志存储的是消息的持久化信息，

五、controller设计

在一个kafka集群中，某个broker会被选举为controller，controller是用来管理和协调Kafka集群的，管理集群中所有分区的状态并执行相应的管理操作。

①更新集群元数据信息

②创建topic

③删除topic

④分区rebalance

⑤prefferd leader选举

⑥topic分区扩展

⑦broker加入集群

⑧broker崩溃

⑨受控关闭

⑩controller leader选举

六、集群管理