Kafka设计

持久化

文件系统

Kafka在消息的存储和缓存中重度依赖文件系统。

磁盘如果合理使用，性能可以非常高。

在一个6张7200转磁盘组成的RAID-5阵列上，线性写性能达到600MB/s，随机写却只有100k/s

磁盘在线性写在某些场景比内存随机写性能更高。

索引

读：通过稀疏索引加快读

写：追加

归档：只保留近一段时间的日志

性能

需要解决下面两个问题：

• 大量的小型IO操作

  通过多个包合并发送

• 过多的字节拷贝

  减少字节拷贝：producer、borker、consumer公用数据结构

  sendfile：零拷贝发送

  1vN：零拷贝

• 端到到批量压缩

生产者

• 生产者直接发包到broker
• 批量发送，减少服务器IO

消费者

• push vs pull：

  由于每个消费者的处理能力都不一样，如果使用push，但速度大于消费速度，消费者将不堪重负

  使用pull，可以让消费者控速

  pull的缺点是，在broker没有数据的时候，消费者会不断轮询

• 消费者位置

  每个消费者对应的分区都有一个offset

  消费者可以指定offset开始消费

消息交付保证

• At most once
• At least once
• Exactly once

kafka提供 At most once和 At least once.不提供Exactly once

生产者交付保证

生产者写数据时，会有ack是否提交完成过的确认。

0：不等待broker返回确认消息

1：leader保存成功返回

-1：所有ISR副本都保存成功返回

消费者交付保证

• 消费者读取消息，保存位置，再进行处理消息（此时消费者有可能崩溃）
• 消费者读取消息，处理消息，再保存位置

复制

• 每个topic有多个partition，每个partition有多个副本，当集群中的节点出现故障时，能自动进行故障转移，保证数据的可用性
• 当slaves处于非活跃状态，会导致吞吐率受到严重影响
• 所有的读写都在leader上进行
• 当消息都在所有分区写到log后，被认为时commited，只有commited的数据才会同步到消费者

ISR与选举

ISR全称a set of in-sync replicas

只要是这个集合里面的副本，都可以被选举为leader

kafka不使用多数投票的方式来选举leader，是因为如果有一般的节点挂掉，将不能有leader

kafka使用元素据来选举leader，在ISR里面的，他们的数据都是最新的，所以他们都有资格成为leader，但大部分节点出现故障，kafka集群依然可以正常运行

全部节点挂掉并重启

有两种方式恢复：

• 等待一个ISR的副本恢复正常工作，并选为leader
• 选择第一个重新恢复正常服务的副本（不一定是ISR）

kafka默认选择第二种方式，可以通过配置来选择第一种策略

配额

kafka对每个生产者和消费者都有一个配额，当他们处理的数据大于配额，kafka将会下降他们的速率，避免单个客户端影响整个集群的状态