Kafka(二） —— Server端设计原理

整理架构

消息设计



/**

 * 消息类

 *

 * @author Michael Fang

 * @since 2019-11-14

 */

public class Message implements Serializable{

    // 2字节

    private short magic;

    // 2字节

    private short codecKlassOrdinal;

    // 1字节

    private boolean codecEnabled;

    // 4字节

    private CRC32 crc;

    // 4字节

    private String key;

    // 4字节

    private String value;

}

（1）一个普通的Kafka消息对象有多大

这个Message对象被创建好实际的大小是多少？

JMM要求Java对象必须按照8Byte对齐，未对齐的部分会填充空白字节进行补齐。

外加64位JVM对象头通常由两个8Byte的word组成。

所以如果是64位JVM，则对象大小 = 16byte(对象头=存放Class指针的空间大小8字节 + MarkWord8字节) + 2 + 2 + 1 + 4 + 4 + 4 +7(补充字节) = 40byte，

如果是32位JVM，则对象大小 = 8byte(对象头=存放Class指针的空间大小4字节 + MarkWord4字节) + 2 + 2 + 1 + 4 + 4 + 4 + 7（补充字节）= 32byte。

一个普通的Kafka消息对象就要40KB的内存空间，显然是比较大的，其中7个字节被浪费掉。

集群管理

kafka依赖Zk，每个broker启动都会在zk中注册一个节点。

从图中的ephemeralOwner字段值可以看出，这是个临时节点。图中的值表示节点绑定的session-id。如果值为0，则表示不是临时节点。

Zk的路径:

/broker:保存Kafka集群的所有信息
/controller：保存Kafka controller组件的注册信息
/admin:
/isr_change_notification
/cofig
/cluster
/controller_epoch

副本与ISR

（1）何为ISR，为什么要有ISR?

ISR是Kafka集群维护的一组同步副本集合（in-sync replicas）。

leader副本对外服务，follower副本向leader副本请求数据，保持与leader副本的同步。

如果leader副本挂掉，从其他follower副本中中选择出一个数据同步进步落后太多的follwer作为leader，会导致数据丢失的问题。

所以引入ISR的概念。

（2）follower副本同步与HW、LEO

HW：高水印值，意思是consumer能够获取的消息上限offset，超过HW的消息，视为“未提交成功”。

LEO：副本日志中下一条写入消息的offset。每个副本都需要维护自己的LEO信息。

在ack = -1的语义下，

当leader接收一条消息后，会把LEO值往后挪动1位，假设为1。

当其他follower都接收到这条消息后，都将LEO值往后挪动1位。

leader接收到follower的响应后，更新HW值为1，则位移为0的消息可以被consumer消费。

（3）如何界定ISR?

0.9版本之前是，replica.lag.max.messages、replica.lag.time.max.ms，意思是当follower落后多少条信息或在多少毫秒内无法向leader请求数据，就会被踢出ISR。

0.9版本以后，只保留replica.lag.time.max.ms。

follower与leader不同步的原因：

请求速度跟不上
进程卡住
新创建副本：新follower副本，需要从头开始追赶。

0.9版本之前的设计，有个问题是，replica.lag.max.messages参数不好设定，容易导致某follower频繁被踢出、加入ISR，导致很大的性能开销。

日志存储设计

文件目录布局

当创建topic的时候，kafka会为每个分区创建对应的文件夹，格式是<topic>-<分区号>。例如创建分区为4，名称为test-partition-1的topic。

向Log中追加消息是顺序写入的，只有最后一个LogSegment才能执行写入，最后一个LogSegment也叫activeSegment。当activeSegment满足一定条件时，需要创建一个新的activeSegment。

日志索引

使用索引的目的是提高查找消息的效率。

每个LogSegment都对应两个索引文件，.index偏移量索引文件、.timeindex时间戳索引文件。

偏移量索引的格式:

relativeOffset:相对偏移量。占用4byte。
postition：物理地址，消息在日志分段分拣中对应的物理位置。占用4byte。

使用二分法实现消息的快速查找，例如要获得offset为35的消息，则找到小于offset=35的最大索引项，该索引项为[31,1050]，然后从1050byte处顺序搜索记录，直到找到offset=35的消息记录。

时间戳索引的格式：

查找timeStamp = 1526384718288的消息，消息查找过程如下：

磁盘存储

Kafka依赖文件系统（磁盘）来存储和缓存消息。磁盘在介质存储速度层级中处于尴尬的位置，那Kafka是如何提供有竞争力的性能呢？

（1）文件追加

顺序写盘的速度，比随机写盘的速度快，也比随机写内存的速度快。

Kafka采用文件追加的方式写入消息，即只在文件的尾部追加新的消息，并且不允许修改已写入的消息。

（2）页缓存（PageCache）

页缓存是操作系统实现的一种重要的磁盘缓存，以此用来减少对磁盘I/O的操作。

页缓存，就是将磁盘中的数据缓存到内存中，将对磁盘的访问变为内存的访问。

读取流程：

当一个进程准备读取磁盘中的文件内容时，操作系统会先判断读取的数据所在的页，是否存在页缓存中，存在则返回数据。不存在，则操作系统向磁盘发送读取请求，并将读取的数据存入页缓存中，再将数据返回给进程。

写入流程：

当进程准备将数据写入磁盘，操作系统会判断数据是否在页缓存中，不存在，则给页缓存增加相应的页，最后将数据写入对应的页。操作系统会在合适的时间，将缓存页中的数据写入磁盘，保证数据一致性。

kafka大量使用页缓存，这是Kafka实现高吞吐的重要原因之一。消息都是先被写入页缓存，然后OS负责具体的刷盘任务。

（3）零拷贝（Zero Copy）

零拷贝：将数据直接从磁盘文件复制到网卡设备中，而不需要经由应用程序之手。

对Linux系统而言，零拷贝技术依赖底层的sendfile()方法实现。对Java而言，FileChannal.transferTo()的底层实现就是sendfile()。

不使用非零拷贝技术的流程：

当需要将一个文件展示给用户时，需要将文件从磁盘中复制到内存buf中，然后将buf通过Socket传输给用户。

在这个过程中文件经历了4次复制过程：

调用read()，文件内容复制到内核模式的Read Buffer中
CPU控制将内核模式的数据复制到用户模式下
调用write()，将用户模式下的内容复制到内核模式下的Socket Buffer中
将内核模式下的Socket Buffer的数据复制到网卡设备中传送

使用零拷贝技术的流程：

应用程序直接请求内核把磁盘中的数据传输给Socket。

零拷贝技术通过DMA技术将文件内容复制到内核模式下的Read Buffer中。相比不使用零拷贝技术，数据只经历了2次复制，上下文切换也减少为2次。

controller（控制器）设计

（1）controller概念

controller是在Kafka集群中，某个broker会被选举出来承担特殊的角色，用来管理集群中所有分区的状态并执行相应的管理操作。

每个Kafka集群中任意时刻都只能有一个controller，集群启动，所有broker会竞选controller，选举工作依赖Zk。

controller相比broker增加的职责如下：

监听分区相关的变化
监听主题相关的变化
监听broker相关的变化
更新集群的元数据信息
启动并管理分区状态机和副本状态机

参考文档

JVM JMM 运行时数据区（内存结构）

Java对象结构及大小计算

 Kafka副本同步机制理解

 图解Kafka的零拷贝技术到底有多牛？

kafka 解密：破除单机topic数多性能下降魔咒