Broker的实现逻辑-kafka知识体系3

作者 | 小汪哥写代码
来源 | 小汪哥(ID：xwgcoding)

上篇文章分享了kafka 生产端的逻辑，以及消息发送到缓存后由sender线程发送到Broker,那么Broker 是怎么进行数据接收和持久化的呢?下面我们从Broker 的网络设计聊起。

Broker 网络设计

kafka的网络设计和Kafka的调优有关，这也是为什么它能支持高并发的原因。

Kafka的网络三层架构

首先客户端发送请求全部会先发送给一个Acceptor，broker里面会存在3个线程(默认是3个)，这3个线程都是叫做processor，

Acceptor不会对客户端的请求做任何的处理，直接封装成一个个socketChannel发送给这些processor形成一个队列，发送的方式是轮询，就是先给第一个processor发送，然后再给第二个，第三个，然后又回到第一个。

消费者线程去消费这些socketChannel时，会获取一个个request请求，这些request请求中就会伴随着数据。

线程池里面默认有8个线程，这些线程是用来处理request的，解析请求，如果request是写请求，就写到磁盘里。读的话返回结果。processor会从response中读取响应数据，然后再返回给客户端。这就是Kafka的网络三层架构。

调优点1

所以如果我们需要对kafka进行增强调优，增加processor并增加线程池里面的处理线程，就可以达到效果。request和response那一块部分其实就是起到了一个缓存的效果，是考虑到processor们生成请求太快，线程数不够不能及时处理的问题。所以这就是一个加强版的reactor网络线程模型。

Broker数据存储设计

【partition 的数据文件】

我们知道topic 是逻辑上的概念，partition是topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。

例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4 存储路径和目录规则为：xxx/message-folder

|--report_push-0
|--report_push-1
|--report_push-2
|--report_push-3
|--launch_info-0
|--launch_info-1
|--launch_info-2
|--launch_info-3

而partition物理上由多个segment组成。

【segment】log

每个segment 大小相等，顺序读写.

每个segment数据文件以该段中最小的offset 命名，文件扩展名为.log

日志回滚受log.segment.bytes控制，默认1G;

这样在查找指定offset 的Message 的时候，用二分查找(跳表)就可以定位到该Message 在哪个segment 数据文件中.

在磁盘上，一个partition就是一个目录，然后每个segment由一个index文件和一个log文件组成。如下：

$ tree kafka | head -n 6
kafka
├── events-1
│ ├── 00000000003064504069.index
│ ├── 00000000003064504069.log
│ ├── 00000000003065011416.index
│ ├── 00000000003065011416.log

Segment下的log文件就是存储消息的地方

每个消息都会包含消息体、offset、timestamp、key、size、压缩编码器、校验和、消息版本号等。

在磁盘上的数据格式和producer发送到broker的数据格式一模一样，也和consumer收到的数据格式一模一样。由于磁盘格式与consumer以及producer的数据格式一模一样，这样就使得Kafka可以通过零拷贝(zero-copy)技术来提高传输效率。

【segment】index

索引文件是内存映射(memory mapped)的。

索引文件，一个稀疏格式的索引，受参数log.index.interval.bytes控制，默认4KB。即不是每条数据都会写索引，默认每写4KB数据才会写一条索引。

Kafka 为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index.

index 文件中并没有为数据文件中的每条 Message 建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引.

这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。

有关内存映射：

即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以Kafka的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。Memory Mapped Files(后面简称mmap)也被翻译成内存映射文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上(操作系统在适当的时候)。通过mmap，进程像读写硬盘一样读写内存，也不必关心内存的大小有虚拟内存为我们兜底。mmap其实是Linux中的一个用来实现内存映射的函数，在Java NIO中可用MappedByteBuffer来实现内存映射。

【Kafka中通过offset查询消息内容的整个流程】

Kafka 中存在一个 ConcurrentSkipListMap 来保存在每个日志分段。

offset-->concurrentSkipListMap-->找到baseOffset对应的日志分段-->读取索引文件.index-->找打不大于offset-baseoffset的最大索引项-->读取分段文件(.log)-->从日志分段文件(.log)中顺序查找

当前索引文件的文件名即为 baseOffset 的值。

【日志留存策略】

Kafka 会定期检查是否要删除旧消息，见参数 log.retention.check.interval.ms，默认5分钟。当前有三种日志留存策略：

基于空间：log.retention.bytes，默认未开启;

基于时间：log.retention.hours(mintues/ms)，默认7天;

基于起始位移：Kafka 0.11.0.0版本引入，解决流处理场景中已处理的中间消息删除问题。

目前基于时间的日志留存策略最常使用。

调优点2

即尽力保持客户端版本和 Broker 端版本一致

即尽力保持客户端版本和 Broker 端版本一致。不要小看版本间的不一致问题，它会令 Kafka 丧失很多性能收益，比如 Zero Copy。

图中蓝色的 Producer、Consumer 和 Broker 的版本是相同的，它们之间的通信可以享受 Zero Copy 的快速通道;相反，一个低版本的 Consumer 程序想要与 Producer、Broker 交互的话，就只能依靠 JVM 堆中转一下，丢掉了快捷通道，就只能走慢速通道了。因此，在优化 Broker 这一层时，你只要保持服务器端和客户端版本的一致，就能获得很多性能收益了。

Broker 副本机制

分区副本默认1，见参数default.replication.factor。

【副本作用(并不提供读写分离)】

1、实现冗余，提高消息可靠性

2、实现高可用，参与leader选举，在leader不可用时提高可用性。

3、leader处理partition的所有读写请求;follower会被动定期地去复制leader上的数据

【leader副本选举】

1、由控制器负责

2、选举机制或策略

所有的副本(replicas)统称为Assigned Replicas，即AR

副本同步队列(ISR)

SR是AR中的一个子集，由leader维护ISR列表，follower从leader同步数据有一些延迟。任意一个超过阈值都会把follower剔除出ISR, 存入OSR(Outof-Sync Replicas)列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR

基本策略是从AR中找第一个存活的副本，且该副本在ISR中。

3、leader来维护：leader有单独的线程定期检测ISR中follower是否脱离ISR, 如果发现ISR变化，则会将新的ISR的信息返回到Zookeeper的相关节点中。

【副本机制的好处】

通常来讲副本机制的好处：

1、提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。

2、提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。

3、改善数据局部性。允许将数据放入与用户地理位置相近的地方，从而降低系统延时。

对于 Apache Kafka 而言，目前只能享受到副本机制带来的第 1 个好处，也就是提供数据冗余实现高可用性和高持久性。

对于客户端用户而言，Kafka 的追随者副本没有任何作用，它既不能像 MySQL 那样帮助领导者副本“抗读”，也不能实现将某些副本放到离客户端近的地方来改善数据局部性。

Broker 高水位机制

【概念】

HW即高水位，是Kafka副本对象的重要属性，分区的高水位由leader副本的高水位表示，含义是被follower副本同步之后的位置。

对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费

【作用】

定义消息可见性，只有分区高水位以下的消息才能被消费;

帮助kafka完成副本同步，kafka是基于高水位实现的异步的副本同步机制。

【LEO的概念】

含义是日志末端位移(Log End Offset)，下一条消息写入的位移。

总结为什么MySQL的索引不采用kafka的索引机制?

既然kafka那么优秀那么快，为什么MySQL的索引不采用kafka的索引机制?

我们还要考虑一个问题：InnoDB中维护索引的代价比Kafka中的要高。Kafka中当有新的索引文件建立的时候ConcurrentSkipListMap才会更新，而不是每次有数据写入时就会更新，这块的维护量基本可以忽略，B+树中数据有插入、更新、删除的时候都需要更新索引，还会引来“页分裂”等相对耗时的操作。Kafka中的索引文件也是顺序追加文件的操作，和B+树比起来工作量要小很多。

其实说到底还是应用场景不同所决定的。MySQL中需要频繁地执行CRUD的操作，CRUD是MySQL的主要工作内容，而为了支撑这个操作需要使用维护量大很多的B+树去支撑。Kafka中的消息一般都是顺序写入磁盘，再到从磁盘顺序读出(不深入探讨page cache等)，他的主要工作内容就是：写入+读取，很少有检索查询的操作，换句话说，检索查询只是Kafka的一个辅助功能，不需要为了这个功能而去花费特别太的代价去维护一个高level的索引。前面也说过，Kafka中的这种方式是在磁盘空间、内存空间、查找时间等多方面之间的一个折中。