一.Kafka的持久化
1.數據持久化：
發現線性的訪問磁盤（即：按順序的訪問磁盤），很多時候比隨機的內存訪問快得多，而且有利於持久化；
傳統的使用內存做為磁盤的緩存
Kafka直接將數據寫入到日志文件中，以追加的形式寫入
2.日志數據持久化特性：
寫操作：通過將數據追加到文件中實現
讀操作：讀的時候從文件中讀就好了
3.優勢：
讀操作不會阻塞寫操作和其他操作（因為讀和寫都是追加的形式，都是順序的，不會亂，所以不會發生阻塞），數據大小不對性能產生影響；
沒有容量限制（相對於內存來說）的硬盤空間建立消息系統；
線性訪問磁盤，速度快，可以保存任意一段時間！
4.持久化的具體實現：
1.一個Topic可以認為是一類消息，每個topic將被分成多partition(區),每個partition在存儲層面是append log文件。任何發布到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱為offset（偏移量）,partition是以文件的形式存儲在文件系統中。
2.Logs文件根據broker中的配置要求,保留一定時間后刪除來釋放磁盤空間。
5.索引
為數據文件建索引：
稀疏存儲，每隔一定字節的數據建立一條索引（這樣的目的是為了減少索引文件的大小）。
下圖為一個partition的索引示意圖：
注：
1.現在對6.和8建立了索引，如果要查找7，則會先查找到8然后，再找到8后的一個索引6，然后兩個索引之間做二分法，找到7的位置
2.每一個log文件中又分為多個segment
二.Kafka的分布式實現
注:
1.當生產者將消息發送到Kafka后，就會去立刻通知ZooKeeper，會往zookeeper的節點中去掛，
zookeeper中會watch到相關的動作，當watch到相關的數據變化后，會通知消費者去消費消息。
2.消費者是主動去Pull（拉）kafka中的消息，這樣可以降低Broker的壓力，因為Broker中的消息是無狀態的，Broker也不知道哪個消息是可以消費的
3.當消費者消費了一條消息后，也必須要去通知ZooKeeper。zookeeper會記錄下消費的數據，這樣但系統出現問題后就可以還原，可以知道哪些消息已經被消費了
部署圖：
Name Server集群即ZooKeeper集群
三.Kafka的通訊協議
注：
最重要的是要理解使用CRC機制來驗證數據是否傳輸不完整，破損。
下面的了解即可
四、數據傳輸的事務定義
at most once: 最多一次,這個和JMS中"非持久化"消息類似.發送一次,無論成敗,將不會重發.
at least once: 消息至少發送一次,如果消息未能接受成功,可能會重發,直到接收成功.
exactly once: 消息只會發送一次.
◦at most once: 消費者fetch消息,然后保存offset,然后處理消息;當client保存offset之后,但是在消息處理過程中出現了異常,導致部分消息未能繼續處理.那么此后"未處理"的消息將不能被fetch到,這就是"at most once".
◦
◦at least once: 消費者fetch消息,然后處理消息,然后保存offset.如果消息處理成功之后,但是在保存offset階段zookeeper異常導致保存操作未能執行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的消息,這就是"at least once"，原因offset沒有及時的提交給zookeeper，zookeeper恢復正常還是之前offset狀態.
◦
◦exactly once: kafka中並沒有嚴格的去實現(基於2階段提交,事務),我們認為這種策略在kafka中是沒有必要的.
注：通常情況下"at-least-once"是我們首選.(相比at most once而言,重復接收數據總比丟失數據要好).
參考資料：
《百知教育》apache kafka