kafka經典入門
阿新 • • 發佈：2017-08-03
stat 緩存 大於 分區 依然 fig tin 發送消息 ray
| 問題導讀 1.Kafka獨特設計在什麽地方？ 2.Kafka如何搭建及創建topic、發送消息、消費消息？ 3.如何書寫Kafka程序？ 4.數據傳輸的事務定義有哪三種？ 5.Kafka判斷一個節點是否活著有哪兩個條件？ 6.producer是否直接將數據發送到broker的leader(主節點)？ 7.Kafa consumer是否可以消費指定分區消息？ 8.Kafka消息是采用Pull模式，還是Push模式？ 9.Procuder API有哪兩種？ 10.Kafka存儲在硬盤上的消息格式是什麽？  一、基本概念 介紹 Kafka是一個分布式的、可分區的、可復制的消息系統。它提供了普通消息系統的功能，但具有自己獨特的設計。 這個獨特的設計是什麽樣的呢？ 首先讓我們看幾個基本的消息系統術語： Kafka將消息以topic為單位進行歸納。 將向Kafka topic發布消息的程序成為producers. 將預訂topics並消費消息的程序成為consumer. Kafka以集群的方式運行，可以由一個或多個服務組成，每個服務叫做一個broker. producers通過網絡將消息發送到Kafka集群，集群向消費者提供消息，如下圖所示：  客戶端和服務端通過TCP協議通信。Kafka提供了Java客戶端，並且對多種語言都提供了支持。 Topics 和Logs 先來看一下Kafka提供的一個抽象概念:topic. 一個topic是對一組消息的歸納。對每個topic，Kafka 對它的日誌進行了分區，如下圖所示：  每個分區都由一系列有序的、不可變的消息組成，這些消息被連續的追加到分區中。分區中的每個消息都有一個連續的序列號叫做offset,用來在分區中唯一的標識這個消息。 在一個可配置的時間段內，Kafka集群保留所有發布的消息，不管這些消息有沒有被消費。比如，如果消息的保存策略被設置為2天，那麽在一個消息被發布的兩天時間內，它都是可以被消費的。之後它將被丟棄以釋放空間。Kafka的性能是和數據量無關的常量級的，所以保留太多的數據並不是問題。 實際上每個consumer唯一需要維護的數據是消息在日誌中的位置，也就是offset.這個offset有consumer來維護：一般情況下隨著consumer不斷的讀取消息，這offset的值不斷增加，但其實consumer可以以任意的順序讀取消息，比如它可以將offset設置成為一個舊的值來重讀之前的消息。 以上特點的結合，使Kafka consumers非常的輕量級：它們可以在不對集群和其他consumer造成影響的情況下讀取消息。你可以使用命令行來"tail"消息而不會對其他正在消費消息的consumer造成影響。 將日誌分區可以達到以下目的：首先這使得每個日誌的數量不會太大，可以在單個服務上保存。另外每個分區可以單獨發布和消費，為並發操作topic提供了一種可能。 分布式 每個分區在Kafka集群的若幹服務中都有副本，這樣這些持有副本的服務可以共同處理數據和請求，副本數量是可以配置的。副本使Kafka具備了容錯能力。 每個分區都由一個服務器作為“leader”，零或若幹服務器作為“followers”,leader負責處理消息的讀和寫，followers則去復制leader.如果leader down了，followers中的一臺則會自動成為leader。集群中的每個服務都會同時扮演兩個角色：作為它所持有的一部分分區的leader，同時作為其他分區的followers，這樣集群就會據有較好的負載均衡。 Producers Producer將消息發布到它指定的topic中,並負責決定發布到哪個分區。通常簡單的由負載均衡機制隨機選擇分區，但也可以通過特定的分區函數選擇分區。使用的更多的是第二種。 Consumers 發布消息通常有兩種模式：隊列模式（queuing）和發布-訂閱模式(publish-subscribe)。隊列模式中，consumers可以同時從服務端讀取消息，每個消息只被其中一個consumer讀到；發布-訂閱模式中消息被廣播到所有的consumer中。Consumers可以加入一個consumer 組，共同競爭一個topic，topic中的消息將被分發到組中的一個成員中。同一組中的consumer可以在不同的程序中，也可以在不同的機器上。如果所有的consumer都在一個組中，這就成為了傳統的隊列模式，在各consumer中實現負載均衡。如果所有的consumer都不在不同的組中，這就成為了發布-訂閱模式，所有的消息都被分發到所有的consumer中。更常見的是，每個topic都有若幹數量的consumer組，每個組都是一個邏輯上的“訂閱者”，為了容錯和更好的穩定性，每個組由若幹consumer組成。這其實就是一個發布-訂閱模式，只不過訂閱者是個組而不是單個consumer。  由兩個機器組成的集群擁有4個分區 (P0-P3) 2個consumer組. A組有兩個consumerB組有4個 相比傳統的消息系統，Kafka可以很好的保證有序性。 傳統的隊列在服務器上保存有序的消息，如果多個consumers同時從這個服務器消費消息，服務器就會以消息存儲的順序向consumer分發消息。雖然服務器按順序發布消息，但是消息是被異步的分發到各consumer上，所以當消息到達時可能已經失去了原來的順序，這意味著並發消費將導致順序錯亂。為了避免故障，這樣的消息系統通常使用“專用consumer”的概念，其實就是只允許一個消費者消費消息，當然這就意味著失去了並發性。 在這方面Kafka做的更好，通過分區的概念，Kafka可以在多個consumer組並發的情況下提供較好的有序性和負載均衡。將每個分區分只分發給一個consumer組，這樣一個分區就只被這個組的一個consumer消費，就可以順序的消費這個分區的消息。因為有多個分區，依然可以在多個consumer組之間進行負載均衡。註意consumer組的數量不能多於分區的數量，也就是有多少分區就允許多少並發消費。 Kafka只能保證一個分區之內消息的有序性，在不同的分區之間是不可以的，這已經可以滿足大部分應用的需求。如果需要topic中所有消息的有序性，那就只能讓這個topic只有一個分區，當然也就只有一個consumer組消費它。 ########################################### 二、環境搭建 Step 1: 下載Kafka 點擊下載最新的版本並解壓.
Step 2: 啟動服務 Kafka用到了Zookeeper，所有首先啟動Zookper，下面簡單的啟用一個單實例的Zookkeeper服務。可以在命令的結尾加個&符號，這樣就可以啟動後離開控制臺。
現在啟動Kafka:
Step 3: 創建 topic 創建一個叫做“test”的topic，它只有一個分區，一個副本。
可以通過list命令查看創建的topic:
除了手動創建topic，還可以配置broker讓它自動創建topic. Step 4:發送消息. Kafka 使用一個簡單的命令行producer，從文件中或者從標準輸入中讀取消息並發送到服務端。默認的每條命令將發送一條消息。 運行producer並在控制臺中輸一些消息，這些消息將被發送到服務端：
ctrl+c可以退出發送。 Step 5: 啟動consumer Kafka also has a command line consumer that will dump out messages to standard output. Kafka也有一個命令行consumer可以讀取消息並輸出到標準輸出：
你在一個終端中運行consumer命令行，另一個終端中運行producer命令行，就可以在一個終端輸入消息，另一個終端讀取消息。 這兩個命令都有自己的可選參數，可以在運行的時候不加任何參數可以看到幫助信息。 Step 6: 搭建一個多個broker的集群 剛才只是啟動了單個broker，現在啟動有3個broker組成的集群，這些broker節點也都是在本機上的： 首先為每個節點編寫配置文件：
在拷貝出的新文件中添加以下參數：
broker.id在集群中唯一的標註一個節點，因為在同一個機器上，所以必須制定不同的端口和日誌文件，避免數據被覆蓋。 We already have Zookeeper and our single node started, so we just need to start the two new nodes: 剛才已經啟動可Zookeeper和一個節點，現在啟動另外兩個節點：
創建一個擁有3個副本的topic:
現在我們搭建了一個集群，怎麽知道每個節點的信息呢？運行“"describe topics”命令就可以了：
下面解釋一下這些輸出。第一行是對所有分區的一個描述，然後每個分區都會對應一行，因為我們只有一個分區所以下面就只加了一行。 leader：負責處理消息的讀和寫，leader是從所有節點中隨機選擇的. replicas：列出了所有的副本節點，不管節點是否在服務中. isr：是正在服務中的節點. 在我們的例子中，節點1是作為leader運行。 向topic發送消息：
消費這些消息：
測試一下容錯能力.Broker 1作為leader運行，現在我們kill掉它：
另外一個節點被選做了leader,node 1 不再出現在 in-sync 副本列表中：
雖然最初負責續寫消息的leader down掉了，但之前的消息還是可以消費的：
看來Kafka的容錯機制還是不錯的。 ################################################ 三、搭建Kafka開發環境 我們搭建了kafka的服務器，並可以使用Kafka的命令行工具創建topic，發送和接收消息。下面我們來搭建kafka的開發環境。 添加依賴 搭建開發環境需要引入kafka的jar包，一種方式是將Kafka安裝包中lib下的jar包加入到項目的classpath中，這種比較簡單了。不過我們使用另一種更加流行的方式：使用maven管理jar包依賴。 創建好maven項目後，在pom.xml中添加以下依賴：
添加依賴後你會發現有兩個jar包的依賴找不到。沒關系我都幫你想好了，點擊這裏下載這兩個jar包，解壓後你有兩種選擇，第一種是使用mvn的install命令將jar包安裝到本地倉庫，另一種是直接將解壓後的文件夾拷貝到mvn本地倉庫的com文件夾下，比如我的本地倉庫是d:\mvn,完成後我的目錄結構是這樣的：  配置程序 首先是一個充當配置文件作用的接口,配置了Kafka的各種連接參數：
producer
consumer
簡單的發送接收 運行下面這個程序，就可以進行簡單的發送接收消息了：
高級別的consumer 下面是比較負載的發送接收的程序：
############################################################ 四、數據持久化 不要畏懼文件系統! Kafka大量依賴文件系統去存儲和緩存消息。對於硬盤有個傳統的觀念是硬盤總是很慢，這使很多人懷疑基於文件系統的架構能否提供優異的性能。實際上硬盤的快慢完全取決於使用它的方式。設計良好的硬盤架構可以和內存一樣快。 在6塊7200轉的SATA RAID-5磁盤陣列的線性寫速度差不多是600MB/s，但是隨即寫的速度卻是100k/s，差了差不多6000倍。現代的操作系統都對次做了大量的優化，使用了 read-ahead 和 write-behind的技巧，讀取的時候成塊的預讀取數據，寫的時候將各種微小瑣碎的邏輯寫入組織合並成一次較大的物理寫入。對此的深入討論可以查看這裏，它們發現線性的訪問磁盤，很多時候比隨機的內存訪問快得多。 為了提高性能，現代操作系統往往使用內存作為磁盤的緩存，現代操作系統樂於把所有空閑內存用作磁盤緩存，雖然這可能在緩存回收和重新分配時犧牲一些性能。所有的磁盤讀寫操作都會經過這個緩存，這不太可能被繞開除非直接使用I/O。所以雖然每個程序都在自己的線程裏只緩存了一份數據，但在操作系統的緩存裏還有一份，這等於存了兩份數據。 另外再來討論一下JVM,以下兩個事實是眾所周知的： ?Java對象占用空間是非常大的，差不多是要存儲的數據的兩倍甚至更高。 ?隨著堆中數據量的增加，垃圾回收回變的越來越困難。 基於以上分析，如果把數據緩存在內存裏，因為需要存儲兩份，不得不使用兩倍的內存空間，Kafka基於JVM，又不得不將空間再次加倍,再加上要避免GC帶來的性能影響，在一個32G內存的機器上，不得不使用到28-30G的內存空間。並且當系統重啟的時候，又必須要將數據刷到內存中（ 10GB 內存差不多要用10分鐘），就算使用冷刷新（不是一次性刷進內存，而是在使用數據的時候沒有就刷到內存）也會導致最初的時候新能非常慢。但是使用文件系統，即使系統重啟了，也不需要刷新數據。使用文件系統也簡化了維護數據一致性的邏輯。 所以與傳統的將數據緩存在內存中然後刷到硬盤的設計不同，Kafka直接將數據寫到了文件系統的日誌中。 常量時間的操作效率 在大多數的消息系統中，數據持久化的機制往往是為每個cosumer提供一個B樹或者其他的隨機讀寫的數據結構。B樹當然是很棒的，但是也帶了一些代價：比如B樹的復雜度是O(log N)，O(log N)通常被認為就是常量復雜度了，但對於硬盤操作來說並非如此。磁盤進行一次搜索需要10ms，每個硬盤在同一時間只能進行一次搜索，這樣並發處理就成了問題。雖然存儲系統使用緩存進行了大量優化，但是對於樹結構的性能的觀察結果卻表明，它的性能往往隨著數據的增長而線性下降，數據增長一倍，速度就會降低一倍。 直觀的講，對於主要用於日誌處理的消息系統，數據的持久化可以簡單的通過將數據追加到文件中實現，讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，並且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優勢是很明顯的，因為性能和數據的大小沒有關系了。 既然可以使用幾乎沒有容量限制（相對於內存來說）的硬盤空間建立消息系統，就可以在沒有性能損失的情況下提供一些一般消息系統不具備的特性。比如，一般的消息系統都是在消息被消費後立即刪除，Kafka卻可以將消息保存一段時間（比如一星期），這給consumer提供了很好的機動性和靈活性，這點在今後的文章中會有詳述。 ############################################################ 五、消息傳輸的事務定義 之前討論了consumer和producer是怎麽工作的，現在來討論一下數據傳輸方面。數據傳輸的事務定義通常有以下三種級別：
如果producer發布消息時發生了網絡錯誤，但又不確定實在提交之前發生的還是提交之後發生的，這種情況雖然不常見，但是必須考慮進去，現在Kafka版本還沒有解決這個問題，將來的版本正在努力嘗試解決。 並不是所有的情況都需要“精確的一次”這樣高的級別，Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。 現在從consumer的方面考慮這個問題，所有的副本都有相同的日誌文件和相同的offset，consumer維護自己消費的消息的offset，如果consumer不會崩潰當然可以在內存中保存這個值，當然誰也不能保證這點。如果consumer崩潰了，會有另外一個consumer接著消費消息，它需要從一個合適的offset繼續處理。這種情況下可以有以下選擇：
############################################################ 六、性能優化 Kafka在提高效率方面做了很大努力。Kafka的一個主要使用場景是處理網站活動日誌，吞吐量是非常大的，每個頁面都會產生好多次寫操作。讀方面，假設每個消息只被消費一次，讀的量的也是很大的，Kafka也盡量使讀的操作更輕量化。 我們之前討論了磁盤的性能問題，線性讀寫的情況下影響磁盤性能問題大約有兩個方面：太多的瑣碎的I/O操作和太多的字節拷貝。I/O問題發生在客戶端和服務端之間，也發生在服務端內部的持久化的操作中。 消息集（message set） 為了避免這些問題，Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作為處理的單位。以消息集為單位處理消息，比以單個的消息為單位處理，會提升不少性能。Producer把消息集一塊發送給服務端，而不是一條條的發送；服務端把消息集一次性的追加到日誌文件中，這樣減少了瑣碎的I/O操作。consumer也可以一次性的請求一個消息集。 另外一個性能優化是在字節拷貝方面。在低負載的情況下這不是問題，但是在高負載的情況下它的影響還是很大的。為了避免這個問題，Kafka使用了標準的二進制消息格式，這個格式可以在producer,broker和producer之間共享而無需做任何改動。 zero copy Broker維護的消息日誌僅僅是一些目錄文件，消息集以固定隊的格式寫入到日誌文件中，這個格式producer和consumer是共享的，這使得Kafka可以一個很重要的點進行優化：消息在網絡上的傳遞。現代的unix操作系統提供了高性能的將數據從頁面緩存發送到socket的系統函數，在linux中，這個函數是sendfile. 為了更好的理解sendfile的好處，我們先來看下一般將數據從文件發送到socket的數據流向：
這顯然是低效率的，有4次拷貝和2次系統調用。Sendfile通過直接將數據從頁面緩存發送網卡接口緩存，避免了重復拷貝，大大的優化了性能。 在一個多consumers的場景裏，數據僅僅被拷貝到頁面緩存一次而不是每次消費消息的時候都重復的進行拷貝。這使得消息以近乎網絡帶寬的速率發送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因為數據都是從頁面緩存中直接發送到網絡上去了。 這篇文章詳細介紹了sendfile和zero-copy技術在Java方面的應用。 數據壓縮 很多時候，性能的瓶頸並非CPU或者硬盤而是網絡帶寬，對於需要在數據中心之間傳送大量數據的應用更是如此。當然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息，但是這將導致較低的壓縮率，因為相比於將消息單獨壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。 Kafka采用了端到端的壓縮：因為有“消息集”的概念，客戶端的消息可以一起被壓縮後送到服務端，並以壓縮後的格式寫入日誌文件，以壓縮的格式發送到consumer，消息從producer發出到consumer拿到都被是壓縮的，只有在consumer使用的時候才被解壓縮，所以叫做“端到端的壓縮”。 Kafka支持GZIP和Snappy壓縮協議。更詳細的內容可以查看這裏。 ########################################################## 七、Producer和Consumer Kafka Producer消息發送 producer直接將數據發送到broker的leader(主節點)，不需要在多個節點進行分發。為了幫助producer做到這點，所有的Kafka節點都可以及時的告知:哪些節點是活動的，目標topic目標分區的leader在哪。這樣producer就可以直接將消息發送到目的地了。 客戶端控制消息將被分發到哪個分區。可以通過負載均衡隨機的選擇，或者使用分區函數。Kafka允許用戶實現分區函數，指定分區的key，將消息hash到不同的分區上(當然有需要的話，也可以覆蓋這個分區函數自己實現邏輯).比如如果你指定的key是user id，那麽同一個用戶發送的消息都被發送到同一個分區上。經過分區之後，consumer就可以有目的的消費某個分區的消息。 異步發送 批量發送可以很有效的提高發送效率。Kafka producer的異步發送模式允許進行批量發送，先將消息緩存在內存中，然後一次請求批量發送出去。這個策略可以配置的，比如可以指定緩存的消息達到某個量的時候就發出去，或者緩存了固定的時間後就發送出去（比如100條消息就發送，或者每5秒發送一次）。這種策略將大大減少服務端的I/O次數。 既然緩存是在producer端進行的，那麽當producer崩潰時，這些消息就會丟失。Kafka0.8.1的異步發送模式還不支持回調，就不能在發送出錯時進行處理。Kafka 0.9可能會增加這樣的回調函數。見Proposed Producer API. Kafka Consumer Kafa consumer消費消息時，向broker發出"fetch"請求去消費特定分區的消息。consumer指定消息在日誌中的偏移量（offset），就可以消費從這個位置開始的消息。customer擁有了offset的控制權，可以向後回滾去重新消費之前的消息，這是很有意義的。 推還是拉？ Kafka最初考慮的問題是，customer應該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push。在這方面，Kafka遵循了一種大部分消息系統共同的傳統的設計：producer將消息推送到broker，consumer從broker拉取消息。 一些消息系統比如Scribe和Apache Flume采用了push模式，將消息推送到下遊的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對於不同消費速率的consumer就不太好處理了。消息系統都致力於讓consumer以最大的速率最快速的消費消息，但不幸的是，push模式下，當broker推送的速率遠大於consumer消費的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統的pull模式。 Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker拉取數據。Push模式必須在不知道下遊consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之後批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導致一次只推送較少的消息而造成浪費。Pull模式下，consumer就可以根據自己的消費能力去決定這些策略。 Pull有個缺點是，如果broker沒有可供消費的消息，將導致consumer不斷在循環中輪詢，直到新消息到t達。為了避免這點，Kafka有個參數可以讓consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量發送)。 消費狀態跟蹤 對消費消息狀態的記錄也是很重要的。 大部分消息系統在broker端的維護消息被消費的記錄：一個消息被分發到consumer後broker就馬上進行標記或者等待customer的通知後進行標記。這樣也可以在消息在消費後立馬就刪除以減少空間占用。 但是這樣會不會有什麽問題呢？如果一條消息發送出去之後就立即被標記為消費過的，一旦consumer處理消息時失敗了（比如程序崩潰）消息就丟失了。為了解決這個問題，很多消息系統提供了另外一個個功能：當消息被發送出去之後僅僅被標記為已發送狀態，當接到consumer已經消費成功的通知後才標記為已被消費的狀態。這雖然解決了消息丟失的問題，但產生了新問題，首先如果consumer處理消息成功了但是向broker發送響應時失敗了，這條消息將被消費兩次。第二個問題時，broker必須維護每條消息的狀態，並且每次都要先鎖住消息然後更改狀態然後釋放鎖。這樣麻煩又來了，且不說要維護大量的狀態數據，比如如果消息發送出去但沒有收到消費成功的通知，這條消息將一直處於被鎖定的狀態， Kafka采用了不同的策略。Topic被分成了若幹分區，每個分區在同一時間只被一個consumer消費。這意味著每個分區被消費的消息在日誌中的位置僅僅是一個簡單的整數：offset。這樣就很容易標記每個分區消費狀態就很容易了，僅僅需要一個整數而已。這樣消費狀態的跟蹤就很簡單了。 這帶來了另外一個好處：consumer可以把offset調成一個較老的值，去重新消費老的消息。這對傳統的消息系統來說看起來有些不可思議，但確實是非常有用的，誰規定了一條消息只能被消費一次呢？consumer發現解析數據的程序有bug，在修改bug後再來解析一次消息，看起來是很合理的額呀！ 離線處理消息 高級的數據持久化允許consumer每個隔一段時間批量的將數據加載到線下系統中比如Hadoop或者數據倉庫。這種情況下，Hadoop可以將加載任務分拆，拆成每個broker或每個topic或每個分區一個加載任務。Hadoop具有任務管理功能，當一個任務失敗了就可以重啟而不用擔心數據被重新加載，只要從上次加載的位置繼續加載消息就可以了。 ######################################################### 八、主從同步 Kafka允許topic的分區擁有若幹副本，這個數量是可以配置的，你可以為每個topci配置副本的數量。Kafka會自動在每個個副本上備份數據，所以當一個節點down掉時數據依然是可用的。 Kafka的副本功能不是必須的，你可以配置只有一個副本，這樣其實就相當於只有一份數據。 創建副本的單位是topic的分區，每個分區都有一個leader和零或多個followers.所有的讀寫操作都由leader處理，一般分區的數量都比broker的數量多的多，各分區的leader均勻的分布在brokers中。所有的followers都復制leader的日誌，日誌中的消息和順序都和leader中的一致。flowers向普通的consumer那樣從leader那裏拉取消息並保存在自己的日誌文件中。 許多分布式的消息系統自動的處理失敗的請求，它們對一個節點是否 著（alive）”有著清晰的定義。Kafka判斷一個節點是否活著有兩個條件：
只有當消息被所有的副本加入到日誌中時，才算是“committed”，只有committed的消息才會發送給consumer，這樣就不用擔心一旦leader down掉了消息會丟失。Producer也可以選擇是否等待消息被提交的通知，這個是由參數request.required.acks決定的。 Kafka保證只要有一個“同步中”的節點，“committed”的消息就不會丟失。 Leader的選擇 Kafka的核心是日誌文件，日誌文件在集群中的同步是分布式數據系統最基礎的要素。 如果leaders永遠不會down的話我們就不需要followers了！一旦leader down掉了，需要在followers中選擇一個新的leader.但是followers本身有可能延時太久或者crash，所以必須選擇高質量的follower作為leader.必須保證，一旦一個消息被提交了，但是leader down掉了，新選出的leader必須可以提供這條消息。大部分的分布式系統采用了多數投票法則選擇新的leader,對於多數投票法則，就是根據所有副本節點的狀況動態的選擇最適合的作為leader.Kafka並不是使用這種方法。 Kafaka動態維護了一個同步狀態的副本的集合（a set of in-sync replicas），簡稱ISR，在這個集合中的節點都是和leader保持高度一致的，任何一條消息必須被這個集合中的每個節點讀取並追加到日誌中了，才回通知外部這個消息已經被提交了。因此這個集合中的任何一個節點隨時都可以被選為leader.ISR在ZooKeeper中維護。ISR中有f+1個節點，就可以允許在f個節點down掉的情況下不會丟失消息並正常提供服。ISR的成員是動態的，如果一個節點被淘汰了，當它重新達到“同步中”的狀態時，他可以重新加入ISR.這種leader的選擇方式是非常快速的，適合kafka的應用場景。 一個邪惡的想法：如果所有節點都down掉了怎麽辦？Kafka對於數據不會丟失的保證，是基於至少一個節點是存活的，一旦所有節點都down了，這個就不能保證了。 實際應用中，當所有的副本都down掉時，必須及時作出反應。可以有以下兩種選擇:
這種窘境不只Kafka會遇到，幾乎所有的分布式數據系統都會遇到。 副本管理 以上僅僅以一個topic一個分區為例子進行了討論，但實際上一個Kafka將會管理成千上萬的topic分區.Kafka盡量的使所有分區均勻的分布到集群所有的節點上而不是集中在某些節點上，另外主從關系也盡量均衡這樣每個幾點都會擔任一定比例的分區的leader. 優化leader的選擇過程也是很重要的，它決定了系統發生故障時的空窗期有多久。Kafka選擇一個節點作為“controller”,當發現有節點down掉的時候它負責在遊泳分區的所有節點中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區節點的主從關系。如果controller down掉了，活著的節點中的一個會備切換為新的controller. ################################################### 九、客戶端API Kafka Producer APIs Procuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實現了同一個接口：
Producer API提供了以下功能：
Consumer API有兩個級別。低級別的和一個指定的broker保持連接，並在接收完消息後關閉連接，這個級別是無狀態的，每次讀取消息都帶著offset。 高級別的API隱藏了和brokers連接的細節，在不必關心服務端架構的情況下和服務端通信。還可以自己維護消費狀態，並可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達式。 低級別的API
低級別的API是高級別API實現的基礎，也是為了一些對維持消費狀態有特殊需求的場景，比如Hadoop consumer這樣的離線consumer。 高級別的API
這個API圍繞著由KafkaStream實現的叠代器展開，每個流代表一系列從一個或多個分區多和broker上匯聚來的消息，每個流由一個線程處理，所以客戶端可以在創建的時候通過參數指定想要幾個流。一個流是多個分區多個broker的合並，但是每個分區的消息只會流向一個流。 每調用一次createMessageStreams都會將consumer註冊到topic上，這樣consumer和brokers之間的負載均衡就會進行調整。API鼓勵每次調用創建更多的topic流以減少這種調整。createMessageStreamsByFilter方法註冊監聽可以感知新的符合filter的tipic。 ####################################################### 十、消息和日誌 消息由一個固定長度的頭部和可變長度的字節數組組成。頭部包含了一個版本號和CRC32校驗碼。
日誌一個叫做“my_topic”且有兩個分區的的topic,它的日誌有兩個文件夾組成，my_topic_0和my_topic_1,每個文件夾裏放著具體的數據文件，每個數據文件都是一系列的日誌實體，每個日誌實體有一個4個字節的整數N標註消息的長度，後邊跟著N個字節的消息。每個消息都可以由一個64位的整數offset標註，offset標註了這條消息在發送到這個分區的消息流中的起始位置。每個日誌文件的名稱都是這個文件第一條日誌的offset.所以第一個日誌文件的名字就是00000000000.kafka.所以每相鄰的兩個文件名字的差就是一個數字S,S差不多就是配置文件中指定的日誌文件的最大容量。 消息的格式都由一個統一的接口維護，所以消息可以在producer,broker和consumer之間無縫的傳遞。存儲在硬盤上的消息格式如下所示：
 寫操作消息被不斷的追加到最後一個日誌的末尾，當日誌的大小達到一個指定的值時就會產生一個新的文件。對於寫操作有兩個參數，一個規定了消息的數量達到這個值時必須將數據刷新到硬盤上，另外一個規定了刷新到硬盤的時間間隔，這對數據的持久性是個保證，在系統崩潰的時候只會丟失一定數量的消息或者一個時間段的消息。 讀操作 讀操作需要兩個參數：一個64位的offset和一個S字節的最大讀取量。S通常比單個消息的大小要大，但在一些個別消息比較大的情況下，S會小於單個消息的大小。這種情況下讀操作會不斷重試，每次重試都會將讀取量加倍，直到讀取到一個完整的消息。可以配置單個消息的最大值，這樣服務器就會拒絕大小超過這個值的消息。也可以給客戶端指定一個嘗試讀取的最大上限，避免為了讀到一個完整的消息而無限次的重試。 在實際執行讀取操縱時，首先需要定位數據所在的日誌文件，然後根據offset計算出在這個日誌中的offset(前面的的offset是整個分區的offset),然後在這個offset的位置進行讀取。定位操作是由二分查找法完成的，Kafka在內存中為每個文件維護了offset的範圍。 下面是發送給consumer的結果的格式：
刪除 日誌管理器允許定制刪除策略。目前的策略是刪除修改時間在N天之前的日誌（按時間刪除），也可以使用另外一個策略：保留最後的N GB數據的策略(按大小刪除)。為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現，刪除操作進行時，讀取操作的二分查找功能實際是在一個靜態的快照副本上進行的，這類似於Java的CopyOnWriteArrayList。 可靠性保證 日誌文件有一個可配置的參數M，緩存超過這個數量的消息將被強行刷新到硬盤。一個日誌矯正線程將循環檢查最新的日誌文件中的消息確認每個消息都是合法的。合法的標準為：所有文件的大小的和最大的offset小於日誌文件的大小，並且消息的CRC32校驗碼與存儲在消息實體中的校驗碼一致。如果在某個offset發現不合法的消息，從這個offset到下一個合法的offset之間的內容將被移除。 有兩種情況必須考慮： 1，當發生崩潰時有些數據塊未能寫入。 2，寫入了一些空白數據塊。第二種情況的原因是，對於每個文件，操作系統都有一個inode（inode是指在許多“類Unix文件系統”中的一種數據結構。每個inode保存了文件系統中的一個文件系統對象,包括文件、目錄、大小、設備文件、socket、管道, 等等），但無法保證更新inode和寫入數據的順序，當inode保存的大小信息被更新了，但寫入數據時發生了崩潰，就產生了空白數據塊。CRC校驗碼可以檢查這些塊並移除，當然因為崩潰而未寫入的數據塊也就丟失了。 |
轉自：http://www.aboutyun.com/thread-12882-1-1.html
kafka經典入門