元数据管理metadata：对于集群中的每个broker，保存了整个集群相同的完整元数据信息；元数据信息包括每个主题的所有分区信息：leader、leader_epoch、controller_epoch、isr、replicas等；Kafka客户端可以从任意broker获取所需的元数据信息；broker变更、topic创建、partition增加等需要更新metadata；KafkaController发送更新请求。更新元数据完全由controller驱动，所以controller所在broker上的负载会对这部分操作产生很大的影响（实际上会影响所有controller的操作）。按照目前的设计，controller所在的broker仍然是一个执行其他client请求处理逻辑的普通broker，所以如果controllerbroker忙于处理各种client请求（比如生产消息或者消费消息），那么对于controller的请求这样的更新操作会被积压起来（backlog），导致更新操作延迟甚至取消。可设计VIP通道。ISR：In-SyncReplicas副本同步队列AR：AssignedReplicas所有副本LEO：最新消息的offset+1，也就是下一条消息的偏移量。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-SyncReplicas）列表中，新加入的follower会也先存储在OSR中。AR=ISR+OSR。Kafka为什么快：PageCache缓存、fileChanel+directBuffer顺序写入由于现代操作系统提供了预读和写入技术，顺序写入磁盘在大多数情况下比随机写入内存更快。Zero-copy零拷贝技术减少了BatchingofMessages批处理的拷贝数。合并小的请求，然后以流的方式交互，达到网络的上限。拉取模式使用拉取模式获取消息并消费，与消费者的处理能力一致。选举leader：1.Kafka使用zookeeper选举controller；2、kafka通过controller选择leader和follower，不经过zookeeper。2.1.等待ISR中的任何Replica“存活”并选择它作为Leader2.2。选择第一个“活的”Replica（不一定在ISR中）作为Leader索引：在Kafka中，定位一条消息，然后先根据偏移量从ConcurrentSkipListMap中找到（baseOffset）日志段对应的索引文件，然后读取offset索引索引文件，然后用二分法找到不大于offset-baseOffsetz的最大索引项的offset索引文件，然后读取日志段文件，依次从日志段中查找relativeOffset对应的消息文件。https://blog.csdn.net/qq_4332...consumerload：确定哪个partition的consumergroup位移信息写入__consumers_offsets。具体计算公式：分区的leader所在的broker是选择的coordinatorcobsumer，向coordinator发送心跳。协调器从所有消费者中决定领导者。领导者计算，并发送给协调者，然后同步给其他消费者。Kafka：写（生产）消息：索引文件小，可以直接使用mmap进行内存映射，段文件大，可以使用普通写（FileChannel.write），因为PageCache是??顺序写的，可以实现veryhighperformanceread(Consumption)message：索引文件仍然是通过mmap读取，pagefault中断的可能性很小。Segment可以使用sendfile向消费者发送零拷贝，以达到非常高的性能。RocketMQ：写入（生产）消息：CommitLog和ConsumerQueue都被使用MMAP写入和读取（消费）消息：commitLog和consumerQueue文件都被MMAP读取
