Kafka防止数据丢失的策略

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 = all (或-1) 是消息可靠性和吞吐量折中的方案。产者在发送消息之后，需要等待ISR中所有的副本都成功
写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。
即：在发送消息时，需要leader 向fllow 同步完数据之后，也就是ISR队列中所有的broker
全部保存完这条消息后，才会向ack发送消息，表示发送成功。

手动提交