Kafka是如何保障数据不丢失的？
对于Kafka的Broker而言，Kafka 的复制机制和分区的多副本架构是Kafka 可靠性保证的核心
Kafka 如何保证生产一次性语义？
数据丢失场景：生产者将数据发送给Kafka，数据在网络传输过程中可能丢失
ACK + 重试机制：生产者生产数据写入Kafka，等待Kafka返回ack确认，收到ack，生产者发送下一条
ACK机制：acks = 0/1/all/-1
重试机制: retries = 3 #发送失败的重试次数
A 在 Kafka 中写入两次，产生数据重复的问题
实现：生产者在生产数据的过程中会在每条数据中增加一个数据id，当前这一条数据会比上一条数据id多1 。由Kafka服务端进行判断，会根据id进行判断是否写过该数据:
如果没有写入：写入Kafka；
如果已经写入：直接返回ack.
Kafka 如何保证消费一次性语义？
消费者是根据 offset 来持续消费，只要保证任何场景下消费者都能知道这个分区的 commit offset，并且严格按照 commit offset 来消费即可
commit offset 每个消费者只保存在自己的内存中，如果消费者一旦故障，这个分区的 commit offset 会丢失。
将每个分区的 commit offset 存储在一种可靠的外部存储中，手动管理offset
step1 : 第一次消费根据属性进行消费
step2 : 消费分区数据，处理分区数据
step3 : 如果处理成功，将处理成功的分区的 Offset 进行额外的存储；
step4 : 如果消费者故障，可以从外部存储读取上一次消费的 offset 向 Kafka 进行请求
小结：生产的不丢失，靠它的 ack 和重试机制；生产的不重复，靠它的幂等性机制，增加数据id；消费的不丢失不重复，靠它的 offset 持久化管理来实现。
为什么Kafka 采用稀疏索引而不采用全局索引？
全局索引是每一条数据都有对应的索引，当数据量很大的情况下，采用全局索引，会导致索引文件变得很大，检索数据的过程就会变得非常慢；用稀疏索引，能减小索引文件的大小，可以很快地加载到索引文件，同时也能缩小检索范围，从而提高检索效率。当然稀疏索引只能查到离某条数据索引最近的一个范围，不能精准地找到某条数据。读取数据的时候，需要在这个范围的数据读取对应的数据。
