kafka如何保证数据不丢失

producer

1.ack的策略配置
ack = 0

生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志

ack = 1

生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到来自服务端的成功响应。其实就是消息只发给了leader leader收到消息后会返回ack到producer端。如果消息无法写入leader时(选举、宕机等情况时)，生产都会收到一个错误的响应，为了避免消息丢失，生产者可以选择重发消息，如果消息成功写入，在被其它副本同步数据时leader　　崩溃,那么此条数据还是会丢失，因为新选举的leader是没有收到这条消息，ack设置为1是消息可靠性和吞吐量折中的方案。

ack = all(-1)

生产者在发送消息之后，需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。即：在发送消息时，需要leader 向fllow 同步完数据之后，也就是ISR队列中所有的broker全部保存完这条消息后，才会向ack发送消息，表示发送成功。

2.retries的配置策略
可恢复和不可恢复错误

3.搭配

1.高可用型　　
配置：acks = all，retries > 0 retry.backoff.ms=100(毫秒) (并根据实际情况设置retry可能恢复的间隔时间)　　
优点：这样保证了producer端每发送一条消息都要成功，如果不成功并将消息缓存起来，等异常恢复后再次送。　　
缺点：这样保证了高可用，但是这会导致集群的吞吐量不是很高，因为数据发送到broker之后，leader要将数据同步到fllower上，如果网络带宽、不稳定等情况时，ack响应时间会更长
2.折中型　　
配置：acks = 1  retries > 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)　　
优点：保证了消息的可靠性和吞吐量，是个折中的方案　　缺点：性能处于2者中间
3.高吞吐型 　　
配置：acks = 0　　优点：可以相对容忍一些数据的丢失，吞吐量大，可以接收大量请求　　缺点：不知道发送的消息是否成功

consumer

group.id: consumer group 分组的一个id　　消费者隶属的消费组名称。在kafka中只允许消息只能被某个组里面的一个consumer端消费，
如果为空，则会报异常。　　对于一个新的consumer加入到消费时，肯定会隶属于哪个组，只有这样才能消费数据

auto.offset.reset = earliest(最早) /latest(最晚)从何处开始进行消费，当一个新加入的consumer要进行消费数据，如果这个
consumer是做数据分析工作的，是需要以前的历史数据那就需要从最早的位置消费数据，如果仅仅是查看消费情况，那可以从最晚位置开始消费数
据

enable.auto.commit = true/false(默认true)　　是否开启自动提交消费位移的功能,默认开启.　　当设置为true时，意味着由kafka的
consumer端自己间隔一定的时间会自动提交offset，如果设置成了fasle，也就是由客户端(自己写代码)来提交，那就还得控制提交的时间间隔


auto.commit.interval.msauto.commit.interval.ms　　当enable.auto.commit设置为true时才生效，表示开启自动提交消费位移功能
时自动提交消费位移的时间间隔。