一、數據日誌
進入到日誌目錄裏面有__consumer_offsets_*的文件夾，指的是有一個__consumer_offsets的topic，有50個分區在不同的broker數據目錄中，裏面有topic_0文件夾有00000000000000000000.index、00000000000000000000.log（數據）等，文件夾名稱指的是offset的值，.log數據達到server.properties中配置的數據大小時會生成一個新的.log
二、kafka生產者
1、分區策略
1⃣️、分區的原因
（1）方便在集羣中擴展，每個partition可以通過調整以適應它所在的機器，而一個topic又可以有多個partition組成，因此整個集羣就可以適應任意大小的數據了；
（2）可以提高併發，因爲可以以partition爲單位讀寫。
2⃣️、分區的原則
2、數據可靠性保證
爲保證producer發送的數據，能可靠的發送到指定的topic，topic的每個partition收到producer發送的數據後，都需要向producer發送ack（acknowledgement確認收到），如果producer收到ack，就會進行下一輪的發送，否則重新發送數據。
1⃣️、副本數據同步策略
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⃣️、ack應答機制
對於某些不太重要的數據，對數據的可靠性要求不是很高，能夠容忍數據的少量丟失，所以沒必要等ISR中的follower全部接受成功。所以Kafka爲用戶提供了三種可靠性級別，用戶根據可靠性和延遲的要求進行權衡，選擇以下的配置
ack參數配置：
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⃣️、故障處理細節
LEO：指的是每個副本最大的offset；
HW：指的是消費者能見到的最大的offset，ISR隊列中最小的LEO
（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同步數據。
三、kafka消費者
1、消費方式
consumer採用poll模式從broker中讀取數據。push模式很難適應消費速率不同的消費者，因爲消息發送速率是由broker決定的。
poll模式不足之處是，如果kafka沒有數據，消費者可能會陷入循環中，一直返回空數據。針對這一點，kafka的消費者在消費數據時會傳入一個時長的參數，如果當前沒有數據可供消費，consumer會等待一段時間之後在返回，這段時長即爲timeout。
2、分區分配策略
一個consumer group中有多個consumer，一個topic有多個partition，所以必然會涉及到partition的分配問題，即確定哪個partition由哪個consumer來消費。kafka有兩種分配策略，一個是RoundRobin，一個是Range（默認）。
3、offset的維護
由於consuemr在消費過程中可能會出現斷電宕機等故障，consumer恢復後，需要從故障前的位置繼續消費，所以consumer要記錄自己消費到了哪個offset，以便故障恢復後繼續消費。
kafka0.9版本之前，consumer默認將offset保存在zookeeper中，從0.9版本開始，offset放到了一個內置的topic中__consumer_offsets。
該topic可以消費，修改consumer.properties將exclude.internal.topics=false。
讀取offset
/usr/local/kafka/bin/kafka-console-consumer.sh --topic __consumer_offsets --bootstrap-server kafka-a:9092 --formatter "kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter" --consumer.config /usr/local/kafka/config/consumer.properties --from-beginning
offset : consuemr group + topic + partition
四、kafka高效讀寫數據
1、順序寫磁盤
同樣的磁盤，順序寫能到600M/s，而隨機寫只有100K/s
2、零拷貝
五、zookeeper在kafka中的作用
kafka集羣中有一個broker會選舉爲controller，負責管理集羣broker的上下線，所有的topic的分區副本分配和leader選舉等工作
leader選舉流程
