kafka 难点

参考

Kafka常见面试题
参考文章

重要考点

1. kafka 为什么那么快

   • Cache Filesystem Cache PageCache缓存

   • 顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。

   • Zero-copy 零拷技术减少拷贝次数

传统传输文件流程
1. 硬盘—>内核buf—>用户buf—>socket相关缓冲区—>协议引擎

零拷贝
1. sendfile系统调用，文件数据被copy至内核缓冲区
2. 再从内核缓冲区copy至内核中socket相关的缓冲区
3. 最后再socket相关的缓冲区copy到协议引擎

总结
相较传统read/write方式，2.1版本内核引进的sendfile已经减少了内核缓冲区到user缓冲区，再由user缓冲区到socket相关缓冲区的文件copy，而在内核版本2.4之后，文件描述符结果被改变，sendfile实现了更简单的方式，再次减少了一次copy操作

* Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。

* Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

2. 消息堆积

   1. 消费端宕机
      增加自动拉起脚本 告警
   2. 消费能力弱
      增强消费能力 异常处理
   3. 调节消费参数
      1. max.poll.interval.ms 每次poll消息处理时间调大
      2. max.poll.records 每次拉取消息条数减小
   4. 分片少
   5. 分片不均匀：producer生产时设置key hash到分区均匀

3. rebalance
   原因：

   • 消费者组消费者数量发生变化
   • 主题（Topic）的分区数量发生变化

方案：

• 启用Kafka的自动提交偏移量，防止消息丢失

合理设置消费者参数

• 未能及时发送心跳而Rebalance
  • session.timeout.ms 一次session的连接超时时间
  • heartbeat.interval.ms 心跳时间，一般为超时时间的1/3，Consumer在被判定为死亡之前，能够发送至少 3 轮的心跳请求
• Consumer消费超时而Rebalance
  • max.poll.interval.ms 每隔多长时间去拉取消息。合理设置预期值，尽量但间隔时间消费者处理完业务逻辑，否则就会被coordinator判定为死亡，踢出Consumer Group，进行Rebalance
  • max.poll.records 一次从拉取出来的数据条数。根据消费业务处理耗费时长合理设置，如果每次max.poll.interval.ms 设置的时间较短，可以max.poll.records设置小点儿，少拉取些，这样不会超时。

总之，尽可能在max.poll.interval.ms时间间隔内处理完max.poll.records条消息，让Coordinator认为消费Consumer还活着