數據存儲格式
Kafka的高可靠性的保障來源於其健壯的副本（replication）策略。一個Topic可以分成多個Partition，而一個Partition物理上由多個Segment組成。
Segment分2部分：索引文件和數據文件。索引文件保存元數據，記錄了消息在數據文件中的偏移（offset），消息有固定物理結構，保證了正確的讀取長度。
Segment文件帶來好處：方便過期文件清理。只需要整體刪除過期的Segment。以追加的方式寫消息，順序寫磁盤極大提高了效率。
讀取某offset消息的步驟變為：通過二分查找，找到offset所在Segment。通過Segment的索引文件，找到offset所在數據文件的物理偏移。讀取數據。
副本復制與同步
從外部來看Partition類似一個不斷增長，存儲消息的數組，每個Partition有一個類似MySQL binlog的文件用來記錄數據的寫入。有兩個新名詞，HW（HighWatermark）表示當前Consumer可以看到Partition的offset位置，LEO（LogEndOffset）表示當前Partition最新消息的offset，各個副本單獨維護。為了提高消息可靠性，Partition有N個副本。
N個副本中，有一個Leader，余下N-1個Follower。Kafka的寫操作只在Leader副本上進行。通常這種副本寫有兩種方式：
-
Leader寫日志文件成功即返回成功。這樣如果Follower在同步完數據前Leader當機，數據丟失。這種方式帶來較高效率。
-
Leader等待Follwer寫日志成功並收到返回的acks后，才返回成功。這樣Leader當機，重新選舉的Leader與當機Leader數據一致，數據不丟失。但因為要等待Follwer返回，效率較慢。一般采用少數服從多數的選舉方式，如果要應對f個副本當機，則至少需要2f+1個副本並使中的f+1個寫成功。
Kafka沒有使用上述機制。它實現了ISR（In-Sync Replication）的機制。
ISR（In-Sync Replication）機制
Leader維護一個副本隊列（包含Leader自己），會及時將慢響應的Follwer剔除，並將追上Leader數據的Follower重新加入副本隊列。
這樣要保證數據高可靠所需要的副本數更少。比如應對2台機器的當機，ISR機制只需要3個副本。而上述機制2則需要2*2+1個副本。這樣有效節約了大約一半的存儲空間。
Leader當機，新的Leader是從ISR中按順序選出。Leader恢復后成為Follower，刪除上一個HW后所有數據后，從新的Leader進行同步。
數據可靠性配置
以下邏輯，可以保證一定程序數據可靠。當然副本越多，min.insync.replicas越大，則越可靠，但實際情況需要根據場景在效率與數據可靠上做權衡。
-
副本數設置為3。副本是Kafka實現HA的基礎，通過replication.factor配置
-
min.insync.replicas設置為2。ISR副本隊列中副本最小個數。極端情況下，ISR中只有一個Leader副本，若Leader當機則服務不可用。因此至少配置為2個。若ISR中副本小於這個數字，Producer返回異常。
-
配置Leader選舉條件unclean.leader.election.enable=false，只允許Leader從ISR隊列中選出。
-
request.required.acks=-1（等待ISR中的所有Follower都收到數據才返回成功），producer.type=sync（同步調用）
以上，保證了一個副本所在機器當機，Kafka仍提供服務，且數據正確未丟失。
數據去重
以上配置，保證了只要Leader返回成功，即不存在數據丟失。但考慮一種情況，Producer提交寫請求到Leader后，Producer到Leader網絡斷開，此時Producer認為寫失敗。但實際，Follower正常同步到了Leader數據，HW更新。
此時Producer因為發送失敗，會重發消息。此時Kafka中存在重復數據。這需要在Consume時業務邏輯中去重。Kafka本身不保證數據不重復。
Kafka高效的幾個原因
1）架構層面
1. 一個Topic多Partition部署實現並行處理，線性擴展
2. ISR副本復制機制實現性能與可用性的平衡
2）磁盤優化
1. Partition中順序寫磁盤
2. mmap實現內存批量寫磁盤，減少I/O次數
3）網絡優化
1. sendfile系統調用實現零拷貝，減少上下文切換
2. Producer批量發送，減少網絡I/O次數
3. 支持數據壓縮