遇见 Kafka

---

前言

日常开发中，遇到的那些事

---

一、Kafka 官方文档

• Apache Kafka
• Apache Kafka 中文

---

二、遇见Kafka

2.1、 保证消息不丢失

Producer：消息发送阶段失败导致消息丢失

失败原因

• 由于网络抖动、导致消息无法发送至broker
• 由于消息体过大、超过broker接收范围被broker拒收

优化方案

• 方案一： 增加重试次数， spring.kafka.producer.retries = 3 （建议重试3次）
• 方案一：通过 acks 参数进行优化，spring.kafka.producer.acks = 1 （建议值）

生产者Acks参数配置说明

• acks = 0：默认值，这时如果发生网络抖动， Producer 端并不会校验 ACK 自然也就丢了。
• acks = 1：消息发送 Leader Parition 接收成功就表示发送成功，这时只要 Leader Partition 不 Crash 掉，就可以保证 Leader Partition 不丢数据，但是如果 Leader Partition 异常 Crash 掉了， Follower Partition 还未同步完数据且没有 ACK，这时就会丢数据。
• acks = -1 或者 all： 消息发送需要等待 ISR 中 Leader Partition 和 所有的 Follower Partition 都确认收到消息才算发送成功, 可靠性最高, 但也不能保证不丢数据,比如当 ISR 中只剩下 Leader Partition 了, 这样就变成 acks = 1 的情况了。

Broker：主节点宕机，从节点选举阶段丢失消息（暂时无法避免）

• Kafka Broker 集群接收到数据后会将数据进行持久化存储到磁盘，为了提高吞吐量和性能，采用的是「异步批量刷盘的策略」，也就是说按照一定的消息量和间隔时间进行刷盘。首先会将数据存储到 「PageCache」 中，至于什么时候将 Cache 中的数据刷盘是由「操作系统」根据自己的策略决定或者调用 fsync 命令进行强制刷盘，如果此时 Broker 宕机 Crash 掉，且选举了一个落后 Leader Partition 很多的 Follower Partition 成为新的 Leader Partition，那么落后的消息数据就会丢失。
• 既然 Broker 端消息存储是通过异步批量刷盘的，那么这里就可能会