Kafka Broker
- kafka 第一个启动的Broker在ZooKeeper中创建一个临时节点/controller，让自己成为控制器。其他Broker启动后在控制器节点上创建Watch对象，便接收节点变更通知。
- Kafka利用ZooKeeper来选举控制器，并在节点加入或者退出集群时通知控制器。控制器负责在节点加入或者退出集群时选举分区首领。控制器使用Epoch来防止“脑裂”。
- Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。每个Broker上面可以保存成百上千个不同主题不同分区的副本。
- 副本有两种类型：Leader 副本，Follower 副本。
replica.lag.time.max.ms
为了与首领保持同步，副本一直向首领请求数据，通过查看每一个跟随者请求的偏移量，首领能够知道副本的同步进度。如果10s内，跟随者没有请求任何消息，或者没有请求最新的数据，
它会被认为是不同步的。如果一个副本无法与首领保持一致，那么当首领失效时，它不会成为首领。只有同步副本才可能成为新的首领。
auto.leader.rebalance,enable
除了当前首领之外，每一个分区还有一个首选首领。创建主题时选定的首领就是分区的首选首领。该值默认是true，他会检查首选首领是不是当前的首领，如果不是，且副本是同步的，那么就会触发首领选举，
它会让首选首领成为当前首领。
处理请求
Kafka客户端要自己负责把生产请求和获取请求发送到正确的broker上。如果请求特定分区，且分区首领在另一个broker上，客户端会收到一个非分区首领的错误。
元数据请求，包含了客户端感兴趣的主题列表，服务器端从而得知这些主题所包含的分区，分区包含了哪些副本，哪个副本是首领。元数据请求可以发送给任意一个Broker。
一般情况下，客户端会将这些信息缓存起来，并时不时发送元数据请求来刷新这些信息，从而得知元数据是否发生变更，当客户端接收到非分区首领的错误时，会先刷新元数据然后再重新发起正确的请求。
metadata.max.age.ms
客户端发送元数据请求的频率。
生产请求
包含首领副本的Broker在收到请求时，会对请求做一些验证，之后写入本地文件系统缓存，并不保证何时刷新到磁盘上。因为他依赖复制功能保证持久性。
在写入分区的首领之后，brokers会根据acks参数来响应。如果acks=all，则请求会被保存到一个叫做炼狱的缓冲区里，直到首领发现所有的跟随者副本都复制了消息，才会发出响应。
获取请求
并不是所有保存到分区首领上的数据都可以被客户端读取。大部分客户端只能读取已经被写入所有的同步副本的消息。因为要满足复制功能的一致性原则。分区首领要知道每一个消息被复制到哪个副本上，在消息没有被写入到所有同步副本之前，是不会发送给消费者的，尝试获取这些消息的请求会得到空相应，而不是错误。
没有被足够多的副本复制完成的消息，会被认为是不安全的。如果首领发生崩溃，另一个副本还没有成为首领，那么这些消息就丢失了。如果允许读取这些消息，就会破坏一致性。因为一个消费者发现这个消息存在，而另一消费者发现这个消息并不存在。
延迟时间通过replica.lag.time.max.ms来配置。
物理存储
kafka的基本存储单元是分区。