上一节我们说了生产者是怎么将数据分区的，也就是Producer生产的消息怎么到不同Partition。
1、那我们如何保证Producer发送的数据，能可靠的发送到指定的topic呢？
topic 的每个 partition 收到producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。
2、何时发送ACK？
副本数据同步策略：
Kafka 选择了第二种方案，原因如下：
- 同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
- 虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。
3、leader 收到数据，所有 follower 都开始同步数据，但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去，直到它完成同步，才能发送 ack。这个问题怎么解决呢？
ISR （in-sync replica set ）
- Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集合。
- 当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。
- 如果 follower长时间 未 向 leader 同步数据 ， 则 该 follower 将被踢出ISR ， 该时间阈值由replica.lag.time.max.ms 参数设定。
- Leader 发生故障之后，就会从 ISR 中选举新的 leader。
4、需要等 ISR 中的 follower 全部接收成功，才发送ACK吗？
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 follower 全部接收成功。所以 Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置：
acks 参数配置： 0 、 1、 -1
0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟，broker 一接收到还没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据；
数据没写入，ack发送了，broker崩了，数据完全丢失了。
1：producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么将会丢失数据；
leader落盘了，ack发送了，leader崩了，同步还没同步好，选举follower为leader，follower没数据，数据丢了。
-1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复。
leader和follwer都有数据了，然后leader崩了，ack没发过去，follwer变成了leader，Producer没收到ack，又发送，重复了。
5、如何做到副本间的（leader和follower间）数据一致性？
首先需要知道HW和LEO的意思，看下图：
LEO：指的是每个副本最大的 offset；
HW：指的是消费者能见到的最大的 offset，ISR 队列中最小的 LEO。
通过上面我们可以知道，HW之前的数据，所有的follower都已经同步好了，数据都有了，不会不一致。
（1）follower 故障
follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。
等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。
（2）leader 故障
leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。（丢失一起丢失、重复一起重复）
6、Exactly Once 语义
- 将服务器的 ACK 级别设置为-1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。
- 将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次，即 At Most Once 语义。
- At Least Once 可以保证数据不丢失，但是不能保证数据不重复；
- At Least Once可以保证数据不重复，但是不能保证数据不丢失。
- 但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即 Exactly Once 语义。
在 0.11 版本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。
0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据，Server 端都只会持久化一条。
幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactly Once 语义。即：
At Least Once + 幂等性 = Exactly Once
要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。
Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而Broker 端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。
但是 PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区跨会话的 Exactly Once。
总结：
1、Producer向leader的某个topic的partition发送信息后，partition会向Producer发送ack，ack的配置有三种：1、0、-1，其中如果是1的话，表示leader还没落盘就发送了ack，如果broker崩了，那数据丢失，如果是0的话，leader落盘了，follower还没同步好，leader崩了，follower数据不全， 数据丢失，前两种数据丢失我们一般不接受，所以一般采用-1，follower也落盘了，但是如果这时leader崩了，ack还没发送，那Producer再次发送数据，造成数据新的leader和其他follower数据重复，为了解决这个问题，Produer在初始化时，会分配一个PID，发送数据时，会以<PID, Partition, SeqNumber>做主键，broker 对同一主键的数据，只保留一份，从而避免数据重复，这样就做到了Producer发送数据即不丢失、也不重复。
2、Leader维护了一个ISR集合，如果某个Follower出了问题，则把这个Follower从ISR中移除，Follower加入时，数据同步策略是HW进行同步的，如果Leader崩了，也是从ISR中选Follwer编程Leader，并且其他Follower也是根据HW进行数据同步的。