Kafka原理

分区的Leader与Follower

1、Leader负责读写操作，Follower只负责副本数据同步
2、Leader出现故障，Follower会选择为Leader
3、分区才有Leader、Follower说法
4、Kafka创建topic时候，尽量不让多个分区Leader在一个broker中
5、注意和ZooKeeper区分，ZK主节点负责读写，follower可以读取

AR\ISR\OSR

1、AR表示一个topic下所有副本replica
2、ISR: In Sync Replicas,正在同步的副本
3、OSR:Out of Sync Replicas 不在同步的副本
4、AR= ISR+OSR

leader选举

1、谁来负责选leader：Controller负责选举leader
2、Controller：
        谁是Controller?Kafka中Broker的老大。
        Controller怎么选出来的?ZK负责选举Controller
        Controller有几个?推测就一个
        leader从哪里选接班人：从ISR列表中快速选举
 3、某个broker挂了之后，如何保证partition的leader均匀分布，就是一个broker上存在多个partition的leader节点。执行一下命令：

bin/kafka-Jeader-election,sh --bootstrap-server nodel.itcast.cn:9092 --topic test -.partition=2 --election type preferred

Kafka读写流程

写流程
  。ZK找到partition leader
  。Producer 发送消息给 partition leader，leader开始写入
  。ISR 中的follower开始同步数据，返回leader ack
  。返回 Producer ack
读流程
  。ZK找到partition leader
  。通过ZK 找到消费者对应的offset
  。从offset顺序拉取数据
  。保存offset

Kafka物理存储

 。Kafka数据组织结构 topic->partition->segment 
       segment
            .log数据文件
            .index(稀疏索引)
            .timeindex(根据时间做的索引)
。深入了解读数据的流程
	    。消费者的offset是一个针对partition全局offset
		。可以根据这个ofset找到segment段
		。接着需要将全局的offset转换成segment的同部offset
		。根据局部的offset，就可以从(.index稀疏索引)找到对应的数据位置
		。开始顺序读取 

消息传递的语义性

  Flink里面有对应的每种不同机制的保证，提供Exactly-0nce保障(二阶段事务提交方式)
。At-most once:最多一次(只管把数据消费到，不管有没有成功，可能会有数据丢失)
。At-least once:最少一次(有可能会出现重复消费)
。Exactly-0nce:仅有一次(事务性性的保障，保证消息有且仅被处理一次)     

Kafka如何保障消息不丢失

  如何保证broker消息不丢失：因为有partition 有多个replicas副本，一个broker挂掉，不会导致数据丢失，除非只有一个副本
  生产者消息不丢：ack机制，所有副本同步完成，再写下一条数据
  消费者消息不丢：控制offset，保证消费一次，可以将offset存储到mysql数据库中。

数据积压

生产数据太多，还来不及消费。
那些原因导致数据积压：外部IO,FULL GC。