Kafka设计原理

1.Controller选举机制

1.1 Kafka Controller

在Kafka集群中会有一个or多个Broker，其中有一个Broker会被选举成为Kakka控制器，它负责管理整个集群中所有分区和副本的状态。

     - 当某个分区的Leader副本出现故障时，由控制器复杂为分区选举新的Leader副本。
     - 当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有的Broker更新元数据信息。
     - 当Topic增加分区数量时，由控制器复杂让新的分区通知其它Broker感知到。

1.2 Controller选举机制

当Kafka集群启动的时候，会自动选举一个Broker作为控制器，选举的过程就是让每一个Broker去zookeeper中创建一个 /controller的临时节点，创建成功的Broker就成为控制器。控制器通过注册watcher机制去监听zk的各种节点来监控集群的各种元数据状态。

2.Partition分区副本选举Leader机制

控制器感知到分区Leader所在的Broker挂了以后，控制器从ISR列表中选出第一个Broker作为Leader。副本节点进入ISR集合有两个条件：

  - 副本节点不能产生网络脑裂，必须能和zookeeper保持会话以及跟Leader副本网络连接。
  - 副本鞥能够复制Leader的写提交，并且不能落后太多(同步时间区域间隔不能太大)。

3.消费Offset记录机制

每一个Consumer会定期将自己消费分区的Offset提交给kafka，key = 消费者组ID + Topic + 分区号，value = 当前Offset的值。kafka定期清理topic里的消息，最后保留最新的数据。

4.Consumer Rebalance

消费负载的触发点有三：

  - 消费者数量发生变化，例如新consumer加入或consumer关闭。
  - topic添加了分区
  - 消费者组订阅了更多的topic

kafka在rebalance过程中，消费者无法消费消息，这对kafka的吞吐性能造成影响。
kafka的rebalance分配有3种策略：

  - `Range`：默认的分配策略，根据分区号排序来进行分配。
  - `Round-Robin`：轮询分配，例如1,4,7、2,5,8这样分配模式。
  - `Sticky`：和轮询类似，但是重新负载的时候会遵守均匀分配等原则。

5.HW和LEO

HW：HighWatermark高水位，取的是ISR中最小的LEO(log end offset)作为HW。对于Leader新写入的消息，consumer不能立即消费，Leader会等待该消息被所有的ISR节点同步后更新HW，此时消息才能够被消费者消费，这样就保证了如果Leader所在的Broker节点挂了，该消息仍然可以从新选举的Leader中获取。
kafka的复制机制并不是完全的同步复制模式，但也不是单纯的异步复制。而是通过引入ISR的方式来确保数据不丢失和保证吞吐量。kafka确保消息不丢失的参数：ACKS：

  - acks = 0：表示Producer不需要等待任何确认收到的信息。
  - acks = 1：至少等待Leader成功将数据写入本地Log，但是并没有等待所有Flollower是否成写入，如果此时Flollower没有同步成功，此时Leader又挂机，则消息会丢失。
  - acks = all：Leader需要等待所有备份节点都成功写入日志，这种方式不会丢失数据。

6.Kafka索引文件

每一个Topic的分区都会生成一个默认1GB大小的文件方便做内存映射，以topic名+分区号命名文件。每个文件还对应了一个索引文件，以.index后缀结尾，目的是进一步提高查询效率。索引文件中包括了若干个索引条目，每个条目表示数据文件中一条消息的Offset。