一：Kafka簡介
kafka是最初由Linkedin公司開發，使用Scala語言編寫，Kafka是一個分佈式、分區的、多副本的、多訂閱者的日誌系統(分佈式MQ系統)，可以用於web/nginx日誌，搜索日誌，監控日誌，訪問日誌等等。
kafka目前支持多種客戶端語言：java，python，c++，php等等。
官網：
http://kafka.apache.org
二：Kafka介紹
2.1 Kafka總體結構圖
2.2 kafka名詞解釋及工作方式
• Producer ：消息生產者，就是向kafka broker發消息的客戶端。
• Consumer ：消息消費者，向kafka broker取消息的客戶端
• Topic ：可以理解爲一個隊列。
• Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給所有的consumer）和單播（發給任意一個consumer）的手段。一個topic可以有多個CG。topic的消息會複製（不是真的複製，是概念上的）到所有的CG，但每個CG只會把消息發給該CG中的一個consumer。如果需要實現廣播，只要每個consumer有一個獨立的CG就可以了。要實現單播只要所有的consumer在同一個CG。用CG還可以將consumer進行自由的分組而不需要多次發送消息到不同的topic。
• Broker ：一臺kafka服務器就是一個broker。一個集羣由多個broker組成。一個broker可以容納多個topic。
• Partition：爲了實現擴展性，一個非常大的topic可以分佈到多個broker（即服務器）上，一個topic可以分爲多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的整體（多個partition間）的順序。
• Offset：kafka的存儲文件都是按照offset.kafka來命名，用offset做名字的好處是方便查找。例如你想找位於2049的位置，只要找到2048.kafka的文件即可。當然the first offset就是00000000000.kafka
2.3 kafka設計目標
• 高吞吐量。
• 數據磁盤持久化：消息不在內存中cache，直接寫入到磁盤，充分利用磁盤的順序讀寫性能。
• zero-copy：減少IO操作步驟。
• 支持數據批量發送和拉取。
• 支持數據壓縮。
• Topic劃分爲多個partition，提高並行處理能力。
2.4 kafka特性
• 通過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。
• 高吞吐量：即使是非常普通的硬件kafka也可以支持每秒數十萬的消息。
• 支持同步和異步複製兩種HA。
• Consumer客戶端pull，隨機讀,利用sendfile系統調用，zero-copy ,批量拉數據
• 消費狀態保存在客戶端。====
• 消息存儲順序寫。
• 數據遷移、擴容對用戶透明。
• 支持Hadoop並行數據加載。
• 支持online和offline的場景。
• 持久化：通過將數據持久化到硬盤以及replication防止數據丟失。
• scale out：無需停機即可擴展機器。
• 定期刪除機制，支持設定partitions的segment file保留時間。
2.5 可靠性（一致性)
kafka(MQ)要實現從producer到consumer之間的可靠的消息傳送和分發。傳統的MQ系統通常都是通過broker和consumer間的確認（ack）機制實現的，並在broker保存消息分發的狀態。
即使這樣一致性也是很難保證的。kafka的做法是由consumer自己保存狀態，也不要任何確認。這樣雖然consumer負擔更重，但其實更靈活了。
因爲不管consumer上任何原因導致需要重新處理消息，都可以再次從broker獲得。
2.6 系統擴展性
kafka使用zookeeper來實現動態的集羣擴展，不需要更改客戶端（producer和consumer）的配置。broker會在zookeeper註冊並保持相關的元數據（topic，partition信息等）更新。
而客戶端會在zookeeper上註冊相關的watcher。一旦zookeeper發生變化，客戶端能及時感知並作出相應調整。這樣就保證了添加或去除broker時，各broker間仍能自動實現負載均衡。
2.7 Producer負載均衡和HA機制
• producer根據用戶指定的算法，將消息發送到指定的partition。
• 存在多個partiiton，每個partition有自己的replica，每個replica分佈在不同的Broker節點上。
• 多個partition需要選取出leader partition，leader partition負責讀寫，並由zookeeper負責fail over。
• 通過zookeeper管理broker與consumer的動態加入與離開。
2.8 Consumer的pull機制
由於kafka broker會持久化數據，broker沒有cahce壓力，因此，consumer比較適合採取pull的方式消費數據，具體特點如下：
• 簡化kafka設計，降低了難度。
• Consumer根據消費能力自主控制消息拉取速度。
• consumer根據自身情況自主選擇消費模式，例如批量，重複消費，從指定partition或位置(offset)開始消費等.
2.9 Consumer與topic關係以及機制
本質上kafka只支持Topic.每個consumer屬於一個consumer group;反過來說,每個group中可以有多個consumer.對於Topic中的一條特定的消息,只會被訂閱此Topic的每個group中的一個consumer消費,此消息不會發送給一個group的多個consumer;那麼一個group中所有的consumer將會交錯的消費整個Topic.
如果所有的consumer都具有相同的group,這種情況和JMS queue模式很像;消息將會在consumers之間負載均衡.
如果所有的consumer都具有不同的group,那這就是”發佈-訂閱”;消息將會廣播給所有的消費者。
在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻);每個group中consumer消息消費互相獨立;我們可以認爲一個group是一個”訂閱”者,
一個Topic中的每個partition,只會被一個”訂閱者”中的一個consumer消費,不過一個consumer可以同時消費多個partitions中的消息。
kafka只能保證一個partition中的消息被某個consumer消費時是順序的.事實上,從Topic角度來說,當有多個partitions時,消息仍不是全局有序的.
通常情況下,一個group中會包含多個consumer,這樣不僅可以提高topic中消息的併發消費能力,而且還能提高”故障容錯”性,如果group中的某個consumer失效，那麼其消費的partitions將會有其他consumer自動接管.kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費，否則將意味着某些consumer將無法得到消息.
2.10 broker集羣內broker之間replica機制
kafka中,replication策略是基於partition,而不是topic;kafka將每個partition數據複製到多個server上,任何一個partition有一個leader和多個follower(可以沒有);
備份的個數可以通過broker配置文件來設定.leader處理所有的read-write請求,follower需要和leader保持同步.Follower就像一個”consumer”。
消費消息並保存在本地日誌中;leader負責跟蹤所有的follower狀態,如果follower”落後”太多或者失效,leader將會把它從replicas同步列表中刪除。
當所有的follower都將一條消息保存成功,此消息才被認爲是”committed”,那麼此時consumer才能消費它,這種同步策略,就要求follower和leader之間必須具有良好的網絡環境.
即使只有一個replicas實例存活,仍然可以保證消息的正常發送和接收,只要zookeeper集羣存活即可
本文來自本人學習kafka時從網上的收集總結，向原創致敬！
