kafka知识整理

元数据管理metadata：
对于集群中的每一个broker都保存着相同的完整的整个集群的metadata信息;
metadata信息里包括了每个topic的所有partition的信息: leader, leader_epoch, controller_epoch, isr, replicas等;
Kafka客户端从任一broker都可以获取到需要的metadata信息;
broker变动, topic创建, partition增加等等时机都需要更新metadata;由KafkaController发送更新请求。更新metadata完全由controller来驱动，故controller所在broker的负载会极大地影响这部分操作（实际上，它会影响所有的controller操作）。根据目前的设计，controller所在broker依然作为一个普通broker执行其他的clients请求处理逻辑，所以如果controller broker一旦忙于各种clients请求(比如生产消息或消费消息)，那么这种更新操作的请求就会积压起来(backlog)，造成了更新操作的延缓甚至是被取消。可以设计vip通道。

ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
LEO:最新的消息的offset+1，即下一条的offset。
HW实际上就是ISR中所有副本LEO的最小值

ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

kafka为啥快：
PageCache缓存、fileChanel+directBuffer
顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
Zero-copy 零拷技术减少拷贝次数
Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

选主：
1、kafka利用zookeeper去选举出controller；
2、kafka通过controller选指定出leader和follower，而无需通过zookeeper了。

2.1.等待ISR中的任一个Replica“活”过来，并且选它作为Leader
2.2.选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader

索引：
在Kafka中要定位一条消息，那么首先根据 offset 从 ConcurrentSkipListMap 中来查找到到对应（baseOffset）日志分段的索引文件，然后读取偏移量索引索引文件，之后使用二分法在偏移量索引文件中找到不大于 offset - baseOffset z的最大索引项，接着再读取日志分段文件并且从日志分段文件中顺序查找relativeOffset对应的消息。https://blog.csdn.net/qq_4332...

consumer负载:

确定consumer group位移信息写入__consumers_offsets的哪个分区。具体计算公式：
该分区leader所在的broker就是被选定的coordinator

cobsumer向coordinator发送心跳。coordinator从所有consumer中决定leader。leader算，算好了发给coordinator，然后同步给其他consumer。

Kafka：
写（生产）消息：

index文件较小，可以直接用mmap进行内存映射
segment文件较大，可以采用普通的write（FileChannel.write），由于是顺序写PageCache，可以达到很高的性能

读（消费）消息：

index文件仍然通过mmap读，缺页中断的可能性较小
segment可以使用sendfile进行零拷贝的发送给消费者，达到非常高的性能

RocketMQ：
写（生产）消息：

CommitLog、ConsumerQueue都使用MMAP进行写

读（消费）消息：

commitLog和consumerQueue文件都是MMAP读