kafka如何最大限度的保证数据不丢失
Producer端
1. 调用方式
（1）网络抖动导致消息丢失，Producer 端可以进行重试。
（2）消息大小不合格，可以进行适当调整，符合 Broker 承受范围再发送。
2. ACK 确认机制
将 request.required.acks 设置为 -1/ all
3. 重试次数 retries
retries = Integer.MAX_VALUE
max.in.flight.requests.per.connection = 1
解读： Producer 端就会一直进行重试直到 Broker 端返回 ACK 标识，同时只有一个连接向 Broker 发送数据保证了消息的顺序性。
4. 重试时间 retry.backoff.ms
发送超时的时候两次发送的间隔，避免太过频繁重试，默认值为100ms, 推荐设置为300ms。
Broker端
Broker端丢失数据是由于其刷盘是异步刷盘的，kafka先把数据存储到内存页中，再进行刷盘，而且没有提供同步刷盘的策略，kafka也注意到这一点，所以其分区多副本机制也是为了最大限度的让数据不丢。
我们可以通过以下参数配合来保证：
1.unclean.leader.election.enable：
该参数表示有哪些 Follower 可以有资格被选举为 Leader , 如果一个 Follower 的数据落后 Leader 太多，那么一旦它被选举为新的 Leader， 数据就会丢失，因此我们要将其设置为false，防止此类情况发生。
2.replication.factor：
该参数表示分区副本的个数。建议设置 replication.factor >=3, 这样如果 Leader 副本异常 Crash 掉，Follower 副本会被选举为新的 Leader 副本继续提供服务。
3.min.insync.replicas ：
该参数表示消息至少要被写入成功到 ISR 多少个副本才算"已提交"，建议设置min.insync.replicas > 1, 这样才可以提升消息持久性，保证数据不丢失。
另外我们还需要确保一下 replication.factor > min.insync.replicas, 如果相等，只要有一个副本异常 Crash 掉，整个分区就无法正常工作了，因此推荐设置成： replication.factor = min.insync.replicas +1, 最大限度保证系统可用性。
Consumer端
设置参数 enable.auto.commit = false, 采用手动提交位移的方式。
另外对于消费消息重复的情况，业务自己保证幂等性, 保证只成功消费一次即可。
