一般我们在用到这种消息中件的时候，肯定会考虑要怎样才能保证数据不丢失，在面试中也会问到相关的问题。但凡
遇到这种问题，是指3个方面的数据不丢失，即：producer consumer 端数据不丢失 broker端数据不丢失
下面我们分别从这三个方面来学习，kafka是如何保证数据不丢失的
一.producer 生产端是如何保证数据不丢失的
1.ack的配置策略
acks = 0
生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是
把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer
端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某
一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志。
acks = 1(默认值)
生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到来自服务端的成功响应。其实就是消息只发给了leader leader收到消息后会返回ack到producer端。
如果消息无法写入leader时(选举、宕机等情况时)，生产都会收到一个错误的响应，为了避免消息丢失，生产者可以选择重发消息，如果消息成功写入，在被其它副本同步数据时leader
崩溃,那么此条数据还是会丢失，因为新选举的leader是没有收到这条消息，ack设置为1是消息可靠性和吞吐量折中的方案。
acks = all (或-1)
生产者在发送消息之后，需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。即：在发送
消息时，需要leader 向fllow 同步完数据之后，也就是ISR队列中所有的broker全部保存完这条消息后，才会向ack发送消息，表示发送成功。
2.retries的配置策略
在kafka中错误分为2种，一种是可恢复的，另一种是不可恢复的。
可恢复性的错误：
如遇到在leader的选举、网络的抖动等这些异常时，如果我们在这个时候配置的retries大于0的，也就是可以进行重试操作，那么等到leader选举完成后、网络稳定后，这些
异常就会消息，错误也就可以恢复，数据再次重发时就会正常发送到broker端。需要注意retries(重试)之间的时间间隔，以确保在重试时可恢复性错误都已恢复。
不可恢复性的错误：
如：超过了发送消息的最大值(max.request.size)时，这种错误是不可恢复的，如果不做处理，那么数据就会丢失，因此我们需要注意在发生异常时把这些消息写入到DB、缓存
本地文件中等等，把这些不成功的数据记录下来，等错误修复后，再把这些数据发送到broker端。
我们上面讲了2个配置项的作用，下面结合实际场景如何使用
3.如何选取
1.高可用型
配置：acks = all，retries > 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)
优点：这样保证了producer端每发送一条消息都要成功，如果不成功并将消息缓存起来，等异常恢复后再次发送。
缺点：这样保证了高可用，但是这会导致集群的吞吐量不是很高，因为数据发送到broker之后，leader要将数据同步到fllower上，如果网络带宽、不稳定等情况时，ack响应时间会更长
2.折中型
配置：acks = 1 retries > 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)
优点：保证了消息的可靠性和吞吐量，是个折中的方案
缺点：性能处于2者中间
3.高吞吐型
配置：acks = 0
优点：可以相对容忍一些数据的丢失，吞吐量大，可以接收大量请求
缺点：不知道发送的消息是 否成功
二.consumer端是如何保证数据不丢失的
1.consumer端的配置
group.id: consumer group 分组的一个id auto.offset.reset= earliest(最早) /latest(最晚) enable.auto.commit = true/false