消息的重复消费问题如何解决的 ?
消费者是通过offset来定位消费数据的 , 当消费者出现故障之后会触发重平衡, 会为消费者组中的消费者重新分配消费分区, 正常情况下是没有问题的 , 这也是Kafka提供的消费保障机制
但是在重平衡的过程中 , 因为Kafka默认子每隔5S自动提交偏移量 , 那么就有可能会出现消息丢失和重复消费问题
如果提交偏移量小于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复处理。
解决方案有二种 :
- 设置更小的自动提交偏移量的周期 , 周期越小出现问题的概率也就越小, 对消费者性能和服务器压力的影响就越大(缓解方案,不能从根本上解决问题)
- 消费完毕手动提交偏移量
- 同步提交 : 会阻塞, 效率低 , 但是会重试 , 直到成功为止
- 异步提交 : 不会阻塞 , 效率高 , 但是不会重试 , 可能会出现提交失败问题
- 同步异步结合
基于上面的操作如果因为网络原因, 服务器原因出现偏移量提交失败的情况 , 还是会出现重复消费 , 具体的解决方案其实非常简单, 为每条消息设置一个唯一的标识id , 将已经消费的消息记录保存起来 , 后期再进行消费的时候判断是否已经消费过即可 , 如果已经消费过则不消费 , 如果没有消费过则正常消费
Kafka如何保证消费的顺序性 ?
topic分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。
但是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。
所以，如果你想要顺序的处理Topic的所有消息，那就只提供一个分区。
Kafka的高可用机制有了解过嘛 ?
Kafka作为一款使用比较广泛的消息中间件产品, 本身也提供了一些机制去实现高可用 , 主要包括 :
- Kafka 集群 : 通过集群模式, 保证Brocker的高可用
- 分区备份机制 : Kafka会为每一个分区设置副本 , 可以手动指定副本数量 , 这些副本会分配到Kafka的不同的Brocker上存储 , 这样可以保证Kafka数据高可用
- 重平衡 : 当消费者组中重新加入消费者 , 或者消费者组中有消费者宕机 , 这个时候Kafka会为消费者组中的消费者从新分配消费分区的过程就是再均衡 , 通过重平衡消实现了消费者的高可用
Kafka实现高性能的设计有了解过嘛 ?
Kafka 高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR 数据同步、以及高效的利用磁盘、操作系统特性等。总结一下其实就是五个要点
- 顺序读写
- 消息分区
- 页缓存
- 零拷贝
- 消息压缩
- 分批发送
Kafka数据清理机制了解过嘛 ?
Kafka中的数据保存在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储
日志是分段存储的，一方面能够减少单个文件内容的大小，另一方面，方便kafka 进行日志清理。
日志的清理策略有两个：
- 根据消息的保留时间，当消息在kafka中保存的时间超过了指定的时间，就会触发清理过程 log.retention.hours=168 默认7天
- 根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。kafka会启动一个后台线程，定期检查是否存在可以删除的消息。log.retention.bytes=1073741824 默认1G
通过上面这两个参数来设置，当其中任意一个达到要求，都会执行删除。
使用Kafka如何实现点对点消息和发布订阅消息
Kafka的点对点消息和发布订阅消息是通过消费者组实现的 , 消费者组（Consumer Group）是由一个或多个消费者实例（Consumer Instance）组成的群组，具有可扩展性和可容错性的一种机制。
- 点对点模式 : 让多个消费者在同一个组中, 这样同一个组中只能有有个消费者消费同一个分区的数据就是点对点模式
- 发布-订阅模式 : 让多个消费者处于不同的组 , 这样不同组中的消费者都能消费同一个分区的数据就是发布-订阅模式
