一、 Kafka 消息数据积压，Kafka 消费能力不足怎么处理？

1）如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

二、Kafka 幂等性

Producer 的幂等性指的是当发送同一条消息时，数据在 Server 端只会被持久化一次，数据不丟不重，但是这里的幂等性是有条件的：

1、只能保证 Producer 在单个会话内不丟不重，如果 Producer 出现意外挂掉再重启是无法保证的（幂等性情况下，是无法获取之前的状态信息，因此是无法做到跨会话级别的不丢不重）。

2、幂等性不能跨多个 Topic-Partition，只能保证单个 Partition 内的幂等性，当涉及多个Topic-Partition 时，这中间的状态并没有同步。

三、Kafka 事务

1、Producer 事务
为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID 和Transaction ID 绑定。这样当 Producer重启后就可以通过正在进行的 TransactionID 获得原来的 PID。
为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

2、Consumer 事务
上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

四、Kafka 数据的可靠性

1、生产者producer的消息可靠投递Producer，使用带回调通知的 send(msg,callback)方法，并且设置 acks = all 。它的消息投递 要采用同步的方式。
Producer 要保证消息到达服务器，就需要使用到消息确认机制，必须要拿到服务器端投递成功的响应才会继续往下执行，
如果Producer 将消息投递到服务器端， 服务器来没来得及接收就已经宕机了，则会在 Producer 投递消息时生成记录日志，然后再将消息投递到服务器端，就算服 务器宕机了，等服务器重启之后，也可以根据日志信息完成 消息补偿，确保消息不丢失。
简单来说就是 生产者发送消息的回调应答机制+重试机制

2、副本同步+落盘机制。
在broker 中的配置项 unclean.leader.election.enable = false，保证所有副本同步。同 时，Producer 将消息投递到服务器的时候，我们需要将消息 持久化，也就是说会同步到磁盘。注意，同步到硬盘的过程 中，会有同步刷盘和异步刷盘。如果选择的是同步刷盘，那 是一定会保证消息不丢失的。就算刷盘失败，也可以即时补 偿。但如果选择的是异步刷盘的话，这个时候，消息有一定 概率会丢失。网上有一种说法，说 Kafka 不支持同步刷盘，

3、消费者 Consume可靠消费+重试机制
在消费者端将自动提交改为手动提交，设置 enable.auto.commit 为 false。 在 Kafka 中，消息消费完成 之后，它不会立即删除，而是使用定时清除策略，也就是说， 我们消费者要确保消费成功之后，手动 ACK 提交。如果消费 失败的情况下，我们要不断地进行重试。所以，消费端不要 设置自动提交，一定设置为手动提交才能保证消息不丢失。