1、數據可靠性保證，數據同步
為保證 producer 發送的數據，能可靠的發送到指定的 topic，topic 的每個 partition 收到 producer 發送的數據后，都需要向 producer 發送 ack（acknowledgement 確認收到），如果 producer 收到 ack，就會進行下一輪的發送，否則重新發送數據。
Kafka副本同步選擇了第二種方案，全部同步完成才發送ack，原因如下：
1.同樣為了容忍 n 台節點的故障，第一種方案需要 2n+1 個副本，而第二種方案只需要 n+1 個副本，而 Kafka 的每個分區都有大量的數據，第一種方案會造成大量數據的冗余。
2.雖然第二種方案的網絡延遲會比較高，但網絡延遲對 Kafka 的影響較小。
2、ISR原理，
采用第二種方案之后，設想以下情景：leader 收到數據，所有 follower 都開始同步數據， 但有一個 follower，因為某種故障，遲遲不能與 leader 進行同步，那 leader 就要一直等下去， 直到它完成同步，才能發送 ack。
這個問題怎么解決呢？ 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。
3、acks，副本同步
acks 參數配置：
0：producer 不等待 broker 的 ack，這一操作提供了一個最低的延遲，broker 一接收到還 沒有寫入磁盤就已經返回，當 broker 故障時有可能丟失數據；
1：producer 等待 broker 的 ack，partition 的 leader 落盤成功后返回 ack，如果在 follower 同步成功之前 leader 故障，那么將會丟失數據；
-1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功后才 返回 ack。但是如果在 follower 同步完成后，broker 發送 ack 之前，leader 發生故障，那么會 造成數據重復。
4、如果保證數據一致性
log
LEO：指的是每個副本最大的 offset，日志末端位移，也就是replica中下一條待寫入消息的offset，注意哈，是下一條並且是待寫入的，並不是最后一條,這個LEO個人感覺也就是用來標示follower的同步進度的。；
HW：replica高水印值，副本中最新一條已提交消息的位移。leader 的HW值也就是實際已提交消息的范圍，每個replica都有HW值，但僅僅leader中的HW才能作為標示信息。
（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 同步數據。
注意：這只能保證副本之間的數據一致性，並不能保證數據不丟失或者不重復。
0.11 版本的 Kafka，引入了一項重大特性：冪等性 ， 來確保數據一致性
kafka會引起的幾個問題，及如何解決的
1、kafka如何保證消息發送成功
ack，副本全部同步完才發送ack給生產者，保證消息發送成功
2、ack如果一個副本故障，怎么辦
kafka引入ISR，類似哨兵模式，檢查副本是否故障，在一定時間不響應自動剔除
3、副本如何確保數據一致性
HW、LEO，