kafka存储机制

副本机制（replication）

Kafka 通过多副本机制实现高可用，确保当Kafka集群中某一个Broker宕机的情况下，仍然可用。而 Kafka 的复制算法保证，如果Leader发生故障或者宕机，一个新的Leader会被重新选举出来，并对外提供服务，供客户端写入消息。Kafka 在同步的副本列表中选举一个副本为Leader。在Topic中，每个分区有一个预写式日志文件，每个分区都由一系列有序，不可变的消息组成，这些消息被连续的追加到分区中，分区中的每个消息都包含一个连续的序列号，即：offset。它用于确定在分区中的唯一位置

---

竞选机制

在Kafka中，假如每个Topic的分区有N个副本，由于Kafka通过多副本机制实现故障自动转移，这里需要说明的是，当KafkaController出现故障，进而不能继续管理集群，则那些KafkaController Follower开始竞选新的Leader，而启动的过程则是在KafkaController的startup方法中完成的，然后启动ZookeeperLeaderElector，在创建临时节点，进行session检查，更新leaderId等操作完成后，会调用故障转移函数onBecomingLeader，也就是KafkaController中的onControllerFailover方法，正因为有这样的机制存在，所示当Kafka集群中的某个Broker宕机后，仍然保证服务是可用的
在Kafka中发生复制操作时，确保分区的预写式日志有序的写到其他节点，在N个复制因子中，其中一个复制因子角色为Leader，那么其他复制因子的角色则为Follower，Leader处理分区的所有读写请求，同时，Follower会被动的定期去复制Leader上的数据。以上分析可以总结为以下几点，如下所示：

Leader负责处理分区的所有读写请求。
Follower会复制Leader上数据。（实现高可用）
Kafka 的故障自动转移确保服务的高可用。

总结
1. 第一步，调用startup方法选出leader，或者leader宕机了，follower竞选leader
2. 第二步，在zookeeper中更新leaderId，
3. 第三步，leader负责处理分区的数据的读写，
4. 第四步，follower负责从leader复制数据，（这一步是实现高可用的关键）

---

存储机制

对于消息对应的性能评估，其文件存储机制设计是衡量的关键指标之一，在分析Kafka的存储机制之前，我们先了解Kafka的一些概念：

1.·Broker：Kafka消息中间件节点，一个节点代表一个Broker，多个Broker可以组建成Kafka Brokers，即 Kafka集群，
2.Topic：消息存储主题，即可以理解为业务数据名，Kafka Brokers能够同时负责多个Topic的处理。
3.Partition：针对于Topic来说的，一个Topic上可以有多个Partition，每个Partition上的数据是有序的。
4.Segment：对于Partition更小粒度，一个Partition由多个Segment组成。
5.Offset：每个Partition上都由一系列有序的，不可变的消息组成，这些消息被连续追加到Partition中。而在其中有一个连续的序列号offset，用于标识消息的唯一性。
总结：

1. 通过topic存储分区，
2. 每一个topic下面有多个partition，每一个patition对应一个文件
3. Segment文件由Index File和Data File组成，文件是一一对应的，后缀为 .index 表示索引文件， .log 表示数据文件
4. 通过offset查找消息

---

kafka的offset storage

一般我们就接受了默认的存储（即：存在 ZK 中）。在新版 Kafka 以及之后的版本，Kafka 消费的offset都会默认存放在 Kafka 集群中的一个叫 __consumer_offsets 的topic中。kafka会将最新的offset放入内存中，消费者可以通过获取内存中的offset信息来获取最新值，我们可以通过一个map集合来获取的这个字段，然后通过一个监听线程来来更新offset，然后可以通过获取到这个字段，可视化的显示资格这个消费情况
代码解析

---