Producer 端丢失

Producer 端为了提升发送效率，减少 IO 操作，发送消息的时候是将多个请求异步发送出去，所以 Producer 端消息丢失更多是因为消息根本就没有发送到 Broker 端。

导致 Producer 端没有发送消息成功的有以下原因：

解决方案

Producer 端数据丢失是因为通过异步的方式进行发送的，所以如果此时使用发后即焚的方式发送，即调用 Producer.send(msg) 会立即返回，由于没有回调，可能因网络原因导致 Broker 并没有收到消息，此时就丢失了。

因此可以从以下几方面进行解决 Producer 端消息丢失问题：

Producer 端通过 ACK 配置来确认消息是否生产成功，配置参数如下：

0：由于发送后就自认为发送成功，这时如果发生网络抖动，会造成数据丢失
1：消息发送 Leader 分区并接收成功就表示发送成功，只要 Leader 分区不挂掉，就可以保证数据不丢数据，但是如果 Leader 分区挂掉了，Follower 分区还未同步完数据且没有 ACK，这时就会丢数据
-1 或者 all：消息发送需要等待 ISR 中 Leader 分区和所有的 Follower 分区都确认收到消息才算发送成功, 可靠性最高，但也不能保证不丢数据，比如：当 ISR 中只有 Leader 分区, 这样就变成 acks = 1 的情况了

Broker 接收到数据后会将消息进行持久化到磁盘存储，为了提高吞吐量和性能，采用的是异步批量刷盘的策略，也就是说按照一定的消息量和间隔时间进行刷盘。

首先会将数据存储到 PageCache 中，至于什么时候将 Cache 中的数据刷盘是由操作系统根据自己的策略决定或者调用 fsync 命令进行强制刷盘。如果在同步到 Follower 分区前 Broker 宕机掉，且选举了一个新的 Leader 分区，那么落后的消息数据就会丢失。

既然 Broker 端消息存储是通过异步批量刷盘的，那么就有可能会丢数据。由于 Kafka 中并没有提供同步刷盘的方式，所以单个 Broker 还是很有可能丢失数据的。

kafka 通过多分区多副本机制已经可以最大限度的保证数据不丢失，如果数据已经写入 PageCache 中但是还没来得及刷写到磁盘，此时如果所在 Broker 突然宕机挂掉或者停电，极端情况还是会造成数据丢失。

Broker 端丢失消息是因为通过异步批量刷盘的策略，先将数据存储到 PageCache，再进行异步刷盘。

因此 Kafka 是通过多分区多副本的方式来最大限度的保证数据不丢失。可以通过以下参数配合来保证：

unclean.leader.election.enable：该参数表示有哪些 Follower 可以有资格被选举为 Leader , 如果一个 Follower 的数据落后 Leader 太多，那么一旦它被选举为新的 Leader，数据就会丢失，因此我们要将其设置为false，防止此类情况发生。
replication.factor：该参数表示分区副本的个数。建议设置 replication.factor >=3, 这样如果 Leader 副本挂掉，Follower 副本会被选举为新的 Leader 副本继续提供服务。
min.insync.replicas：该参数表示消息至少要被写入成功到 ISR 多少个副本才算”已提交”，建议设置min.insync.replicas > 1, 这样才可以提升消息持久性，保证数据不丢失。

另外还需要确保一下 replication.factor > min.insync.replicas，如果相等，只要有一个副本挂掉，整个分区就无法正常工作了，因此推荐设置成： replication.factor = min.insync.replicas +1, 最大限度保证系统可用性。

消息消费流程主要分为两个阶段：

Consumer 拉取后消息后需要提交 Offset，那么这里就可能会丢数据的。丢失原因如下：

可能使用的自动提交 Offset 方式
拉取消息后先提交 Offset，后处理消息，如果此时处理消息的时候异常宕机，由于 Offset 已经提交了, 待 Consumer 重启后，会从之前已提交的 Offset 下一个位置重新开始消费，之前未处理完成的消息不会被再次处理，对于该 Consumer 来说消息就丢失了。
拉取消息后先处理消息，在进行提交 Offset，如果此时在提交之前发生异常宕机，由于没有提交成功 Offset，待下次 Consumer 重启后还会从上次的 Offset 重新拉取消息，不会出现消息丢失的情况，但是会出现重复消费的情况，这里只能业务自己保证幂等性。