Kafka拷打！！！

8. Kafka是如何保证消息不丢失？

Kafka 防丢一般从三端保证。生产者端设置acks=all、开启重试和失败回调，必要时开启幂等生产者。Broker 端用多副本，配置合理的replication.factor和min.insync.replicas，并关闭不干净 leader 选举。消费者端关闭自动提交 offset，业务处理成功后再手动提交。这样通常能保证不丢，但可能重复消费，所以业务要做幂等。

9. Kafka中消息的重复消费问题如何解决？

Kafka 重复消费一般不能完全避免，常见情况是业务已经处理成功了，但 offset 还没提交，消费者宕机或者发生 rebalance，之后这条消息会被重新拉取。

因此真正的核心是业务幂等。比如订单支付消息，可以用订单号或者消息唯一 ID 做去重，先判断这条消息或这个订单是否已经处理过；如果已经处理过就直接跳过。数据库层也可以加唯一索引，或者用 Redis 记录已消费消息，保证重复消费不会产生错误结果。

10. Kafka是如何保证消费的顺序性？

Kafka 保证的是单个 Partition 内有序，不保证整个 Topic 多分区的全局顺序。如果业务要求顺序，比如同一个订单的状态变更，就要用相同的业务 key，比如orderId，让这些消息进入同一个 Partition。消费者端也要按顺序处理，不能对同一分区随意并发消费。全局有序可以只用一个 Partition，但吞吐量会下降。

11. Kafka的高可用机制了解吗？

Kafka 的高可用主要是靠集群和分区副本机制实现的。

Kafka 集群里会部署多个 Broker，Topic 会被拆成多个 Partition。每个 Partition 可以配置多个副本，比如 3 副本，其中一个是 leader，其他是 follower。正常情况下，生产者和消费者主要和 leader 交互，follower 会从 leader 同步数据。

如果某个 Broker 宕机，Kafka 的 Controller 会感知到，然后对受影响的 Partition 重新选举 leader。一般会优先从 ISR 里面选新的 leader，因为 ISR 里的副本和原 leader 数据比较同步。这样只要还有可用副本，就可以继续对外提供服务。

12. 解释一下复制机制中的ISR？

是什么->具体情况->作用

ISR 是 Kafka 的同步副本集合，包含 leader 和同步状态良好的 follower。Kafka 会动态维护 ISR，follower 如果长时间落后 leader，就会被踢出 ISR，追上后可以重新加入。leader 宕机时会优先从 ISR 中选新 leader，因为这些副本数据相对最新。它还会配合acks=all和min.insync.replicas提高消息可靠性。

13. Kafka数据清理机制了解吗？

Kafka 的数据清理主要是基于日志保留策略，不是消费者消费完就立即删除。

Kafka 底层是追加写日志，日志会切成多个 segment。
最常见的清理策略是delete，也就是按照保留时间或者日志大小删除旧数据。比如可以配置消息保留 7 天，或者某个 Topic 的日志超过一定大小后，清理最旧的日志段。
除了删除策略，Kafka 还有一种compact日志压缩策略。它不是简单删除旧消息，而是针对相同 key 的消息，只尽量保留最新的一条，适合一些状态类数据，比如配置变更、用户状态或者 CDC 场景。

所以总结一下，Kafka 数据清理主要有两类：一种是按时间或大小删除旧日志，另一种是按 key 做日志压缩。

14. Kafka中实现高性能的设计有了解过吗？

Kafka 高性能主要靠几个设计：
第一是分区机制，一个 Topic 拆成多个 Partition，可以并行写入和消费；
第二是追加写日志，主要走顺序磁盘 IO；
第三是利用操作系统 Page Cache，减少真实磁盘访问；
第四是消费数据时使用零拷贝，减少数据拷贝开销；另外还有批量发送和消息压缩，减少网络 IO，提高整体吞吐量。