本文正在参加「金石计划 . 分割6万现金大奖」
大数据集群框中基本都会运用Kafka，被数千家公司用于高性能的数据管道和要害使命运用。它的主要作用就是接收上游生产者的信息，然后传输给下流消费者，但这个接收上游信息的进程怎样才干确保数据的完整性呢，也就是怎样做到接收进程不丢数据。
那么这就要说到Kafka的数据可靠性确保相关知识，为了做到数据的安全传输，Kafka运用了 ack应对机制，这就类似于网络安全中常用的 TCP的三次握手四次挥手。
ack应对机制
在生产者(producer)往Kafka发送数据的进程中，为了确保数据能够发送到指定的topic中，topic中的每一个partition在收到数据后，都需要向生产者发送 ack（ackacknowledgement）。假设 producer 在必定的时间内收不到应对，那么producer会再次向Kafka发送此条数据。
那么这就类似于写信，假定我们写一封信给或人，然后我们会在一段时间后收到一封回信，但假设超过了一个月我们还没有收到回信，就会猜想是不是信件丢掉了，会将这封信进行从头发送，直到收到回信中止。
1. 那么此时会有个问题，什么时候发送ack?
首要必定不会在leader收到信息之后立马就发送ack，因为假定此时leader遽然挂掉，没有备份，数据会永久丢掉。所以会有这样的三个要害点：（1）leader在内存中接收到producer发送的数据（外网）；（2）leader接收到数据之后会立马进行落盘（写入磁盘） （3）一切的folloewr同步落盘后的数据（内网）
副本数据的同步战略有两种：
- 半数以上完结同步，就发送ack；
- 全部完结同步，才会发送ack
kafka运用第二种同步战略，也就是等到全部的follower完结同步后，leader才会发送ack。
2. ISR机制
等到全部的follower完结同步后才会发送ack，那么这种办法有一个很大的缺陷就是：一切follower同步落盘的数据，可是有一个follower，因为某种毛病，迟迟不能进行同步，那leader就要一直等下去，直到它完结同步，才干发送ack。针对此缺陷，Kafka采用了一个ISR机制，in-sync replica set，意为和 leader坚持同步的follower调集。
假设 ISR 中的 follower 长期未向 leader 同步数据，则该 follower 将被踢出ISR，该时间阈值由replica.lag.time.max.ms(10s) 参数设定。Leader发生毛病之后，就会从ISR中推举新的leader。
3. ack的三种应对等级
Kafka为用户供应了三种可靠性等级，用户依据对可靠性和推延的要求进行权衡，选择以下的配备。因为关于一些不重要的数据，我们能够忍耐数据的少量丢掉，所以不用等ISR中的folloewr全部接收成功。
acks参数配备：
0：
能够供应了一个最低的推延，leader接收到producer的消息后还没有写入磁盘就已经回来ack。那么当leader毛病时或断电时就有或许 丢掉数据；
1：
leader接收到数据而且落盘成功后回来ack，但假设在ISR中的follower同步数据成功之前leader发生毛病，那么将大概率发生 丢掉数据 的情况；
这是因为里边的一种机制会导致数据丢掉–follower的上位机制。leader接收数据进行落盘而且发送ack后遽然挂掉，但follower并没有同步到leader中的数据。此时follower需要上位成为新的leader，新的leader需要和剩下的follower进行数据同步，问询它们的分区offset是从几号开端的，因为它们之前并没有同步 “Hello” 那条数据，所以能够以为它们的分区号都是从0号开端。但反观producer，因为已经收到ack应对，所以不会再重复发送 “Hello” 这条数据，会直接进行下一条数据的传输。而且假设之前挂掉的leader从头发动后，它会作为follower从头参加ISR，它就会去问询新的leader数据的存储情况，因为新的leader中并没有 “Hello” 这条数据，所以这个follower会以为数据存储过错，把 “Hello” 数据删去。
-1（all）：
leader接收数据而且落盘后，同时ISR中的follower全部同步成功后，leader才会发送ack，这是最安全的也是仅有一种不会构成数据丢掉的应对等级。可是这种应对等级也会存在缺陷，比方假设在follower同步完结后，leader还未发送ack之前，leader发生毛病，那么就有或许构成数据重复。
follower同步完数据后，leader还未发送ack遽然挂掉，生产者会再次向新的leader发送同一条数据，因此构成数据的重复。
