kafka基礎概念

kafka介紹

　　kafka is a distributed, partitiononed,replicated commited logservice. kafka是一個分佈式的、易擴展的、安全性高的消息服務系統。kafka提供了相似於JMS的特性，但在設計實現上又徹底不一樣，它並非基於JMS規範實現的（kafka的實現不包含事務特性性）。kafka對消息的保存時以Topic進行歸類的，向Topic發送消息的稱謂Producer,從Topic接受消息的稱謂Consumer。kafka集羣由多個service組成，每一個service在kafka集羣中被稱做broker。kafka集羣的做用就是存儲從Producer發過來的消息，而後按照必定的規則將消息發送給Consumer。不管是kafka集羣自己，仍是Producer 或者Consumer，均依賴於zookeeper來管理集羣中的信息同步。下圖爲kafka基本結構組成圖：

 

kafka系統名詞解釋

• Topics

　　一個topic能夠認爲是一類消息，每一個topic能夠被劃分紅多個partition(區),每一個partition在存儲層面是append log文件。任何發佈到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset(偏移量)，offset爲一個Long型數字，他是log中一條消息的惟一標識。kafka並無提供其餘額外的索引機制來存儲offset,由於kafka的消息讀寫機制是順序讀寫，保證kafka的吞吐率，幾乎不容許（能夠）對消息進行隨機讀取。

 

　　kafka和JMS的實現（activeMQ）不一樣的是：即便消息被消費了，消息仍然不會被當即刪除。日誌文件將會根據broker中的配置要求，將message保留一段時間後再刪除。好比將log文件保留2天，那麼兩天後，該文件將會被刪除，不管其中的消息是否被消費。kafka經過這種簡單的方式來釋放磁盤空間。

　　對於consumer而言，他須要保存消費消息的offset，對於offset的保存和使用，由consumer來控制；當consumer正常消費消息時，offset將會「線性的」向前驅動，即，消息將依照順序被消費。實際上，consumer也能夠經過指定offset來消費特定的消息（offset將會保存在zookeeper中，參見下文）。

　　kafka集羣幾乎不須要維護任何producer和consumer的狀態消息，這些消息由zookeeper來維護保存，所以，producer和consumer的客戶端很是輕量級，他們能夠隨意的加入或者離開，不會對集羣形成額外的影響。

　　partition的設計目的有多個，最根本的緣由是kafka基於文件存儲，經過分區，能夠將日誌內容分佈到多個broker上，避免文件尺寸達到單機的存儲上線。能夠將一個topic劃分紅多個partitions，這樣既能夠下降對單機磁盤容量的要求，又能夠提升系統消息的讀寫速率。此外，越多的partition意味着能夠容納更多的consumer，更有效的提高併發性能。

• Distination

　　一個topic的多個partition被分配在kafka集羣的多個broker上，每一個broker負責partitions中消息的讀寫操做；此外，kafka還能夠配置partition須要的備份個數（replicas），每一個partition將會被備份到多個broker中，這樣就加強了系統的可靠性。

　　基於replicated方案，那麼就意味着須要對多個備份進行調度，每一個partition都有一個broker爲「leader」，其他都爲「follower」。leader負責全部的讀寫操做，若是leader失效，那麼將會有其餘的follower被選舉爲新的leader;follower只是單純的和leader進行消息同步便可。因而可知，部署leader的broker承載了partition所有的請求壓力，所以，從集羣的總體角度考慮，有多少個partition，就有多少個leader，kafka將會將這些leader均衡的分配在broker上，來確保集羣總體的吞吐量和穩定性。

• Producer

　　Producer將消息發佈到指定的topic中，同時，producer還須要指定該消息屬於哪一個partition

• Consumer

　　本質上kafka只支持topic，每個consumer屬於一個consumer group，每一個consumer group能夠包含多個consumer。發送到topic的消息只會被訂閱該topic的每一個group中的一個consumer消費。

　　若是全部的consumer都具備相同的group，這種狀況和queue很類似，消息將會在consumer之間均衡分配；

　　若是全部的consumer都在不一樣的group中，這種狀況就是廣播模式，消息會被髮送到全部訂閱該topic的group中，那麼全部的consumer都會消費到該消息。

　　kafka的設計原理決定，對於同一個topic，同一個group中consumer的數量不能多於partition的數量，不然就會有consumer沒法獲取到消息。

• Guarantees

1. 發送到partition中的消息將會按照它的接受順序追加到日誌中；
2. 對於消費者而言，它的消息消費順序是和日誌中的順序一致的；
3. 若是partition的replicationfactor爲N，那麼就容許N-1個broker失效。

kafka使用場景

• Messaging

　　對於一些常規的消息系統，kafka是個不錯的選擇，partition/replication和容錯，使得kafka具備良好的擴展性和安全性。不過到目前爲止，kafka並無提供JMS中的「事務性」「消息傳輸擔保機制（消息確認機制）」「消息分組」等企業級特性；kafka只能做爲常規的消息系統，在必定程度上，還沒有肯定消息發送與接收的絕對可靠。

• websit activity tracking

　　kafka能夠做爲「網站活性追蹤」的最佳工具；能夠將網頁/用戶操做等信息發送到kafka，進行實時監控或者離線分析等。

• Log Aggregation

　　kafka的特性決定了他很是適合作「日誌手機中心」；application能夠將操做日誌批量「異步」發送到kafka集羣中，而不是保存在本地或者DB中；kafka能夠對消息進行批量的上傳和壓縮等，這對producer而言，幾乎感受不到性能的開銷。此時，consumer端可使用hadoop等其餘系統化的存儲和分析系統。

kafka設計原理

　　kafka設計初衷是但願做爲一個統一的信息收集平臺，可以事實的收集和反饋信息，而且可以支撐較大的數據量，且具有良好的容錯能力。

• 持久性

　　kafka使用文件存儲消息，這就直接決定了kafka在性能上嚴重依賴於文件系統自己的性能。並且，不管在任何OS下，對文件系統自己的優化幾乎沒有了改進的可能。文件緩存/直接內存映射是經常使用的提升文件系統性能的手段。由於kafka是對日誌文件進行append操做，所以磁盤檢索的開銷仍是比較少的，同時，爲了減小磁盤寫入的次數，broker會暫時將消息buffer起來，當消息數量達到了一個閾值，在寫入到磁盤，這樣就能夠減小磁盤IO的次數。

• 性能

　　除了磁盤IO性能意外，咱們還須要考慮網絡IO，這直接關係到kafka的吞吐量問題。kafka並無提供太多高超的技巧。對於producer端而言，能夠將消息buffer起來，當消息數量達到必定的閾值時，批量發送給broker；對於consumer端而言，也能夠批量的fatch消息，不過消息量的大小是能夠經過配置文件進行配置的。對於kafka broker端，sendfile系統調用能夠潛在的提升網絡IO性能：將文件數據映射到系統內存中，socket直接讀取相應的內存區域便可，而不須要進程再次進行copy和交換。對於producer、consumer、broker而言，CPU的開支都不大，所以啓用消息壓縮機制是一個很好的策略；壓縮須要消耗少許的CPU資源，不過對於kafka而言，網絡IO應該更爲重要。能夠經過將任何在網路上傳輸的消息進行壓縮來提升網絡IO性能。kafka支持多種壓縮方式（gzip/snappy）。

• 生產者

　　負載均衡：producer將會和topic下的全部partition leader保持socket鏈接；消息由producer直接經過socket發送個broker，中間不會通過任何「消息路由」，實際上，消息被髮送給哪一個broker由producer端決定。若是一個消息有多個partitions，那麼在producer端實現消息「均衡分發」是頗有必要的。

　　其中partition leader位置（host:port）保存在zookeeper中，producer做爲zookeeper client，已經註冊了watch用來監聽partition leader的變動事件。

　　異步發送：將多條消息暫且保存在producer的buffer中，當達到必定的數量閾值時，將他們一塊兒批量發送給broker，延遲批量發送其實是提升了網絡效率。不過也存在一些隱患，好比當producer失效時，那些還沒有發送出去的消息將會丟失。

• 消費者

　　consumer端向broker發送fatch請求，並告訴其獲取消息的offset，此後，consumer會得到必定數量的消息，consumer端也能夠經過重置offset來從新獲取想要的消息。

　　在JMS中，topic模型是基於push方式的，即broker將消息推送給consumer端。不過在kafka中，採用的是pull模型，即consumer在和broker創建鏈接後，主動去pull(也就是fatch)消息；這種模式有本身的優勢，首先，consumer能夠根據本身的消費需求去fatch合適的消息並進行處理，此外，消費者能夠良好的控制消費消息的數量。

　　在kafka中，partition中的消息只有一個consumer在消費，切不存在消息狀態的控制，也沒有複雜的消息確認機制，可見，kafka broker是至關輕量級的。當消息被consumer接收後，consumer在本地保存最後消費消息的offset，並間歇性的向zookeeper註冊offset。因而可知，consumer也是輕量級的。

 

　　kafka在zookeeper中的存儲結構圖以下所示：

kafka安全機制：partition複製備份

　　kafka將每一個partition數據複製到多個broker上，任何一個partition都有一個leader和多個follower(能夠沒有)。備份的個數能夠經過broker的配置文件進行配置。leader處理全部的read-write請求，follower只須要和leader保持信息同步便可，leader負責跟蹤全部的follower狀態信息，若是follower落後太多或者失效，leader將會把它從replicas同步列表中刪除。當全部的follower將一條消息保存成功，該消息才被認爲是發送成功（committed），此時，consumer才能消費它。即便只有一個replicas存活，仍然能夠保證消息的正常發送和接受，只要zookeeper集羣存活便可。（不一樣於其餘分佈式存儲，須要多數派存活）

　　當leader失效時，須要在follower中選擇一個新的leader（此選舉並不是經過zookeeper進行選舉的），可能此時的follower落後於leader，所以須要一個「up-to-date」的follower。選擇新的leader時也須要同時兼顧一個問題，那就是broker上leader的數量，若是一個server上有多個leader，意味着此service將承受更多的IO壓力，因此在選舉時，須要考慮leader的「負載平衡」。

參考文獻

• kafka入門：簡介、使用場景、設計原理、主要配置及集羣搭建（轉）
• kafka學習筆記：知識點整理