浅谈Kafka中acks参数对消息持久化的影响

在说到Kafka的参数优化时就给大家说过acks参数的意义，这个acks参数在kafka的使用中，是非常核心以及关键的一个参数，决定了很多东西。尤其时数据丢失这方面，能很好解决这类问题。
为了保证producer发送的数据能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后都需要向producer发送确认消息，即acknowledgement确认收到消息，如果producer收到ack就会进行下一轮的发送，否则重新发送数据。

那么所在的broker什么时候发送ack给producer？

1. leader落盘后直接返回ack，如果producer收到ack后leader挂了，follower还未同步成功，造成消息丢失。
2. follower全部同步成功后返回ack，leader选举时容忍n台节点故障，需要n+1个副本，随便选一个follower即可。不过是高延迟，需要等待follower都同步成功。
3. 半数以上follower同步成功后返回ack，选举新leader时，容忍n台节点故障，需要2n+1个副本。

kafka选择所有follower同步成功后再返回ack的方案，原因如下：

• 同样为了容忍n台节点故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而kafka每个分区都有大量的数据，第一种方案会造成大量的数据冗余。
• 第二种方案的网络延迟虽然比较高，但都是一个局域网中，网络延时的影响也比较小。

多副本冗余机制
比如Partition0有一个副本是Leader，另外一个副本是Follower，Leader和Follower两个副本是分布在不同机器上的。这样的多副本冗余机制，可以保证任何一台机器挂掉，都不会导致数据彻底丢失，因为起码还是有副本在别的机器上的。

多副本数据同步
接着我们就来看看多个副本之间数据是如何同步的？其实任何一个Partition，只有Leader是对外提供读写服务的。
也就是说，如果有一个客户端往一个Partition写入数据，此时一般就是写入这个Partition的Leader副本。
然后Leader副本接收到数据之后