Kafka从入门到入门-编程实验室

kafka的出现是为了支持大量消息事件，它的分布式设计、消息抽象设计及存储选择和优化性能手段都高效的支持了它的性能表现，同时面临分布式系统典型的信息同步、中心化设计、负载均衡等问题，对于这些问题kafka也给出了高效和多样化的选择，这也给运维带来一定的复杂性。

架构

消息发送

Broker地址获取：客户端初始化时配置bootstrap.servers，然后获取集群信息并保存到本地缓存，防治过多通信。
分区选择算法：发送消息时可以指定分区、由key来hash分区选择、或者采用默认策略选择分区（粘性分区策略）。
Broker的确认机制：客户端在消息积累一定数量或者超过指定时间后会发送到Broker，Broker会根据配置的acks参数来决定何时返回写入结果。acks参数配置：
1. 为0时：收到消息写入到系统I/O缓存后立即返回（刷盘由操作系统完成）
2. 为1时：收到消息写入主分区的I/O缓存后返回。
3. 为-1时：收到消息写入I/O缓存，等待ISR全部副本拉取完数据并返回LEO，Leader更新HW后返回。
分区数据同步
1. ISR（In-Sync Replicas）机制：保持数据同步和一致性
  AR 表示分配给某个分区的所有副本集合，包括 Leader 和所有 Follower。
  ISR 是 AR 的子集，表示与 Leader 保持同步的副本集合。只有 ISR 中的副本才有资格被选举为新的 Leader。
  OSR 是 AR 的子集，表示不能与 Leader 保持同步的副本集合。消息和leader副本相差replica.lag.time.max.ms则会被归入OSR集合中。
  注意:ISR和OSR都是动态调整的，目的是让副本尽量和Leader副本数据保持一致，保持系统的可用性
2. HW和LEO概念
  LEO 表示每个副本当前最后一条消息的偏移量**+1**，即下一条新消息将要写入的位置。每个副本的"写到哪里了"
  HW 表示已提交消息的偏移量。HW 之前的所有消息都已经成功复制到所有 ISR 副本中。消费者能看到的"最高水位"
3. 副本会定时向Leader副本获取最新数据并更新自己的数据，返回自己的LEO,Leader在收到各个副本的LEO结果后会更新HW，这也对外（消费者可以看到）的消息就不断往前。

消息消费

获取消费协调者
消费者组向任意一个Broker发送FindCoordinator请求，该Broker根据元信息找到该消费者组的GroupCoordinator。对应上图中的1-4过程（GroupCoordinator是Broker上的一个组件用于元数据管理、消费者控制，使用__consumer_offset的topic进行持久化，根据groupId进行__consumer_offset分区的选择，上图是简化了。）
加入消费组
向GroupCoordinator发送JoinGroup请求，GroupCoordinator会选择出消费者Leader进行分区分配，然后同步消费者该信息。消费者根据分配的分区拉取消息，比如上图中Consumer01分配了Partition0和Partition2进行拉取消息进行消费。分区计算可以理解为在客户端（本地）进行计算减少了服务器的压力，只需要把结果同步到GroupCoordinator上。
元信息同步
消费者组加入消费会触发rebalance，ControllerBroker会进行分区分配并同步元信息到各个Broker。

持久化和高性能

Topic是逻辑上的队列，在kafka的分布式设计上Topic又被分成多个分区，可以看成物理上的队列，在系统实现中体现为文件夹。分区的设计既保障了系统的可用性（冗余备份）又保证了系统的高并发性。为了性能考虑，分区实现又把文件进一步拆分限制大小（比如1G）和索引机制（快速查找offset）。

顺序写

kafka在转储消息数据时选择磁盘来作为临时存储，大部分场景消息很快就被消费掉，同时持久化仅防止数据丢失不需要其他常见的分析和查询数据，选择磁盘是合适的。
磁盘存储查询和写入的耗时大家应该都了解在于磁头寻道上，写入读取数据耗时不大，所以顺序读写就显得格外重要，顺序和随机读写性能差异不在一个数量级。