一、發送數據
follower的同步流程
PS：Producer在寫入數據的時候永遠的找leader，不會直接將數據寫入follower
PS：消息寫入leader后，follower是主動的去leader進行同步的！
PS：producer采用push模式將數據發布到broker，每條消息追加到分區中，順序寫入磁盤，所以保證同一分區內的數據是有序的！
PS：往不存在的topic寫數據，kafka會自動創建topic，分區和副本的數量根據默認配置都是1。
分區
主要目的：
方便擴展：因為一個topic可以有多個partition，所以我們可以通過擴展機器去輕松的應對日益增長的數據量。
提高並發：以partition為讀寫單位，可以多個消費者同時消費數據，提高了消息的處理效率。
分發策略：
1、 partition在寫入的時候可以指定需要寫入的partition，如果有指定，則寫入對應的partition。
2、 如果沒有指定partition，但是設置了數據的key，則會根據key的值hash出一個partition。
3、 如果既沒指定partition，又沒有設置key，則會輪詢選出一個partition。
ACK應答機制
在生產者向隊列寫入數據的時候可以設置參數來確定是否確認kafka接收到數據，這個參數可設置的值為0、1、all。（保證消息不丟失）
0：代表producer往集群發送數據不需要等到集群的返回，不確保消息發送成功。安全性最低但是效率最高。
1：代表producer往集群發送數據只要leader應答就可以發送下一條，只確保leader發送成功。
all：代表producer往集群發送數據需要所有的follower都完成從leader的同步才會發送下一條，確保leader發送成功和所有的副本都完成備份。安全性最高，但是效率最低。
二、保存數據
Kafka初始會單獨開辟一塊磁盤空間，順序寫入數據（效率比隨機寫入高），將數據保存在磁盤。
PS：任何發布到 Partition 的消息都會被追加到 Partition 數據文件的尾部，且消息消費后不會刪除（刪除策略是針對過期的 Segment 文件），這樣的順序寫磁盤操作讓 Kafka 的效率非常高（經驗證，順序寫磁盤效率比隨機寫內存還要高，這是 Kafka 高吞吐率的一個很重要的保證）。
Partition 結構
Partition在服務器上的表現形式就是一個一個的文件夾，每個partition的文件夾下面會有多組segment文件，每組segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中沒有）三個文件， log文件就實際是存儲message的地方，而index和timeindex文件為索引文件，用於檢索消息。
PS：Segment 是 Kafka 文件存儲的最小單位。
如上圖，這個partition有三組segment文件，每個log文件的大小是一樣的，但是存儲的message數量是不一定相等的（每條的message大小不一致）。文件的命名是以該segment最小offset來命名的，如000.index存儲offset為0~368795的消息，kafka就是利用分段+索引的方式來解決查找效率的問題。
Message結構
上面說到log文件就實際是存儲message的地方，我們在producer往kafka寫入的也是一條一條的message，message主要包含消息體、消息大小、offset、壓縮類型……等等
offset：offset是一個占8byte的有序id號，它可以唯一確定每條消息在parition內的位置！
消息大小：消息大小占用4byte，用於描述消息的大小。
消息體：消息體存放的是實際的消息數據（被壓縮過），占用的空間根據具體的消息而不一樣。
存儲策略
無論消息是否被消費，kafka都會保存所有的消息（存在磁盤）。那對於舊數據有什么刪除策略呢？
基於時間，默認配置是168小時（7天）。
基於大小，默認配置是1073741824。
需要注意的是，kafka讀取特定消息的時間復雜度是O(1)，所以這里刪除過期的文件並不會提高kafka的性能！
三、消費數據
Kafka采用的是點對點的模式，消費者主動的去kafka集群拉取消息，與producer相同的是，消費者在拉取消息的時候也是找leader去拉取。
- 多個消費者可以組成一個消費者組（consumer group），每個消費者組都有一個組id。
- 同一個消費組的消費者可以消費同一topic下不同分區的數據，但是不會組內多個消費者消費同一分區的數據！！！
- 消費者數少於分區：會出現某個消費者消費多個partition數據的情況（此時消費的速度不及只處理一個partition的消費者的處理速度）
- 消費者數多於分區：多出來的消費者不消費任何partition的數據。
- 建議消費者組的consumer的數量與partition的數量一致！
四、搜索數據
搜索數據樣例解析
假如現在需要查找一個offset為368801的message是什么樣的過程呢？用一個例子來解釋一下搜索過程
- 先找到offset的368801message所在的segment文件（利用二分法查找），這里找到的就是在第二個segment文件。
- 打開找到的segment中的.index文件（也就是368796.index文件，該文件起始偏移量為368796+1，我們要查找的offset為368801的message在該index內的偏移量為368796+5=368801，所以這里要查找的相對offset為5）。利用二分法查找相對offset小於或者等於指定的相對offset的索引條目中最大的那個相對offset，所以找到的是相對offset為4的這個索引。
- 根據找到的相對offset為4的索引確定message存儲的物理偏移位置為256。打開數據文件，從位置為256的那個地方開始順序掃描直到找到offset為368801的那條Message。
PS:注意該 index 文件並不是從0開始，也不是每次遞增1的，這是因為 Kafka 采取稀疏索引存儲的方式，每隔一定字節的數據建立一條索引，它減少了索引文件大小，使得能夠把 index 映射到內存，降低了查詢時的磁盤 IO 開銷，同時也並沒有給查詢帶來太多的時間消耗。
小結：這套機制是建立在offset為有序的基礎上，利用segment+有序offset+稀疏索引+二分查找+順序查找等多種手段來高效的查找數據！至此，消費者就能拿到需要處理的數據進行處理了。
消費者記錄位置的方式
早期的版本：消費者將消費到的offset維護zookeeper中，consumer每間隔一段時間上報一次，這里容易導致重復消費，且高並發時和ZK頻繁交互，性能不好！
新的版本：消費者消費到的offset已經直接維護在kafk集群的__consumer_offsets這個topic中！
參考資料：
- 再過半小時，你就能明白kafka的工作原理了（特此感謝！）