8. Kafka是如何保证消息不丢失Kafka 防丢一般从三端保证。生产者端设置acksall、开启重试和失败回调必要时开启幂等生产者。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 集群里会部署多个 BrokerTopic 会被拆成多个 Partition。每个 Partition 可以配置多个副本比如 3 副本其中一个是 leader其他是 follower。正常情况下生产者和消费者主要和 leader 交互follower 会从 leader 同步数据。如果某个 Broker 宕机Kafka 的 Controller 会感知到然后对受影响的 Partition 重新选举 leader。一般会优先从 ISR 里面选新的 leader因为 ISR 里的副本和原 leader 数据比较同步。这样只要还有可用副本就可以继续对外提供服务。12. 解释一下复制机制中的ISR是什么-具体情况-作用ISR 是 Kafka 的同步副本集合包含 leader 和同步状态良好的 follower。Kafka 会动态维护 ISRfollower 如果长时间落后 leader就会被踢出 ISR追上后可以重新加入。leader 宕机时会优先从 ISR 中选新 leader因为这些副本数据相对最新。它还会配合acksall和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提高整体吞吐量。