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

qezhu521
发布于 2022-4-20 16:40
浏览
0收藏

作者 | 小汪哥写代码
来源 | 小汪哥(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的网络三层架构。Broker的实现逻辑-kafka知识体系3-鸿蒙开发者社区

调优点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。Broker的实现逻辑-kafka知识体系3-鸿蒙开发者社区

图中蓝色的 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中的这种方式是在磁盘空间、内存空间、查找时间等多方面之间的一个折中。

收藏
回复
举报
回复
    相关推荐