kafka入門

基本概念

框架介紹

Kafka是一個分佈式的、可分區的、可複製的消息系統。它提供了普通消息系統的功能,但具有自己獨特的設計。

首先讓我們看幾個基本的消息系統術語:

名稱 說明
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
Broker 一臺kafka服務器就是一個broker。一個集羣由多個broker組成。一個broker可以容納多個topic
Producer 消息生產者,向kafka broker發消息的客戶端
Consumer 消息消費者,向kafka broker取消息的客戶端
Consumer Group 消費者組,這是kafka用來實現一個topic消息的廣播(發給所有的consumer)和單播(發給任意一個consumer)的手段。一個topic可以有多個CG。topic的消息會複製(不是真的複製,是概念上的)到所有的CG,但每個partion只會把消息發給該CG中的一個consumer。如果需要實現廣播,只要每個consumer有一個獨立的CG就可以了。要實現單播只要所有的consumer在同一個CG。用CG還可以將consumer進行自由的分組而不需要多次發送消息到不同的topic;

Kafka將消息以topic爲單位進行歸納。
將向Kafka topic發佈消息的程序成爲producers.
將預訂topics並消費消息的程序成爲consumer.
Kafka以集羣的方式運行,可以由一個或多個服務組成,每個服務叫做一個broker.
producers通過網絡將消息發送到Kafka集羣,集羣向消費者提供消息,如下圖所示:
在這裏插入圖片描述
客戶端和服務端通過TCP協議通信。Kafka提供了Java客戶端,並且對多種語言都提供了支持。

Topic和Log

一個topic是對一組消息的歸納。對每個topic,Kafka 對它的日誌(log)進行了分區(partition),如下圖所示:
在這裏插入圖片描述
每個分區都由一系列有序的、不可變的消息組成,這些消息被連續的追加到分區中。分區中的每個消息都有一個連續的序列號叫做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。
在這裏插入圖片描述
相比傳統的消息系統,Kafka可以很好的保證有序性。

傳統的隊列在服務器上保存有序的消息,如果多個consumers同時從這個服務器消費消息,服務器就會以消息存儲的順序向consumer分發消息。雖然服務器按順序發佈消息,但是消息是被異步的分發到各consumer上,所以當消息到達時可能已經失去了原來的順序,這意味着併發消費將導致順序錯亂。爲了避免故障,這樣的消息系統通常使用“專用consumer”的概念,其實就是隻允許一個消費者消費消息,當然這就意味着失去了併發性。

在這方面Kafka做的更好,通過分區的概念,Kafka可以在多個consumer組併發的情況下提供較好的有序性和負載均衡。將每個分區分只分發給一個consumer組,這樣一個分區就只被這個組的一個consumer消費,就可以順序的消費這個分區的消息。因爲有多個分區,依然可以在多個consumer組之間進行負載均衡。注意consumer組的數量不能多於分區的數量,也就是有多少分區就允許多少併發消費。

Kafka只能保證一個分區之內消息的有序性,在不同的分區之間是不可以的,這已經可以滿足大部分應用的需求。如果需要topic中所有消息的有序性,那就只能讓這個topic只有一個分區,當然也就只有一個consumer組消費它。

數據持久化

Kafka大量依賴文件系統去存儲和緩存消息。與傳統的將數據緩存在內存中然後刷到硬盤的設計不同,Kafka直接將數據寫到了文件系統的日誌中。

在大多數的消息系統中,數據持久化的機制往往是爲每個cosumer提供一個B樹或者其他的隨機讀寫的數據結構。B樹當然是很棒的,但是也帶了一些代價:比如B樹的複雜度是O(log N),O(log N)通常被認爲就是常量複雜度了,但對於硬盤操作來說並非如此。磁盤進行一次搜索需要10ms,每個硬盤在同一時間只能進行一次搜索,這樣併發處理就成了問題。雖然存儲系統使用緩存進行了大量優化,但是對於樹結構的性能的觀察結果卻表明,它的性能往往隨着數據的增長而線性下降,數據增長一倍,速度就會降低一倍。

直觀的講,對於主要用於日誌處理的消息系統,數據的持久化可以簡單的通過將數據追加到文件中實現,讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的,並且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優勢是很明顯的,因爲性能和數據的大小沒有關係了。

既然可以使用幾乎沒有容量限制(相對於內存來說)的硬盤空間建立消息系統,就可以在沒有性能損失的情況下提供一些一般消息系統不具備的特性。比如,一般的消息系統都是在消息被消費後立即刪除,Kafka卻可以將消息保存一段時間(默認情況下是7天),這給consumer提供了很好的機動性和靈活性,這點在今後的文章中會有詳述。

消息傳輸的事務定義

之前討論了consumer和producer是怎麼工作的,現在來討論一下數據傳輸方面。數據傳輸的事務定義通常有以下三種級別:

  • 最多一次(at most one): 消息不會被重複發送,最多被傳輸一次,但也有可能一次不傳輸。
  • 最少一次(at least one): 消息不會被漏發送,最少被傳輸一次,但也有可能被重複傳輸.
  • 精確的一次(Exactly once): 不會漏傳輸也不會重複傳輸,每個消息都傳輸被一次而且僅僅被傳輸一次,這是大家所期望的。

大多數消息系統聲稱可以做到“精確的一次”,但是仔細閱讀它們的的文檔可以看到裏面存在誤導,比如沒有說明當consumer或producer失敗時怎麼樣,或者當有多個consumer並行時怎麼樣,或寫入硬盤的數據丟失時又會怎麼樣。kafka的做法要更先進一些。當發佈消息時,Kafka有一個“committed”的概念,一旦消息被提交了,只要消息被寫入的分區的所在的副本broker是活動的,數據就不會丟失。關於副本的活動的概念,下節文檔會討論。現在假設broker是不會down的。

如果producer發佈消息時發生了網絡錯誤,但又不確定實在提交之前發生的還是提交之後發生的,這種情況雖然不常見,但是必須考慮進去,現在Kafka版本還沒有解決這個問題,將來的版本正在努力嘗試解決。

並不是所有的情況都需要“精確的一次”這樣高的級別,Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通知,或者完全的異步發送消息而不等待任何通知,或者僅僅等待leader聲明它拿到了消息(followers沒有必要)。

現在從consumer的方面考慮這個問題,所有的副本都有相同的日誌文件和相同的offset,consumer維護自己消費的消息的offset,如果consumer不會崩潰當然可以在內存中保存這個值,當然誰也不能保證這點。如果consumer崩潰了,會有另外一個consumer接着消費消息,它需要從一個合適的offset繼續處理。這種情況下可以有以下選擇:

  • consumer可以先讀取消息,然後將offset寫入日誌文件中,然後再處理消息。這存在一種可能就是在存儲offset後還沒處理消息就crash了,新的consumer繼續從這個offset處理,那麼就會有些消息永遠不會被處理,這就是上面說的“最多一次”。
  • consumer可以先讀取消息,處理消息,最後記錄offset,當然如果在記錄offset之前就crash了,新的consumer會重複的消費一些消息,這就是上面說的“最少一次”。
  • “精確一次”可以通過將提交分爲兩個階段來解決:保存了offset後提交一次,消息處理成功之後再提交一次。但是還有個更簡單的做法:將消息的offset和消息被處理後的結果保存在一起。比如用Hadoop ETL處理消息時,將處理後的結果和offset同時保存在HDFS中,這樣就能保證消息和offser同時被處理了。

性能優化

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的數據流向:

  • 操作系統把數據從文件拷貝內核中的頁緩存中
  • 應用程序從頁緩存從把數據拷貝自己的內存緩存中
  • 應用程序將數據寫入到內核中socket緩存中
  • 操作系統把數據從socket緩存中拷貝到網卡接口緩存,從這裏發送到網絡上。

這顯然是低效率的,有4次拷貝和2次系統調用。Sendfile通過直接將數據從頁面緩存發送網卡接口緩存,避免了重複拷貝,大大的優化了性能。

在一個多consumers的場景裏,數據僅僅被拷貝到頁面緩存一次而不是每次消費消息的時候都重複的進行拷貝。這使得消息以近乎網絡帶寬的速率發送出去。這樣在磁盤層面你幾乎看不到任何的讀操作,因爲數據都是從頁面緩存中直接發送到網絡上去了。

數據壓縮

很多時候,性能的瓶頸並非CPU或者硬盤而是網絡帶寬,對於需要在數據中心之間傳送大量數據的應用更是如此。當然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息,但是這將導致較低的壓縮率,因爲相比於將消息單獨壓縮,將大量文件壓縮在一起才能起到最好的壓縮效果。

Kafka採用了端到端的壓縮:因爲有“消息集”的概念,客戶端的消息可以一起被壓縮後送到服務端,並以壓縮後的格式寫入日誌文件,以壓縮的格式發送到consumer,消息從producer發出到consumer拿到都被是壓縮的,只有在consumer使用的時候才被解壓縮,所以叫做“端到端的壓縮”。

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判斷一個節點是否活着有兩個條件:

  • 節點必須可以維護和ZooKeeper的連接,Zookeeper通過心跳機制檢查每個節點的連接。
  • 如果節點是個follower,他必須能及時的同步leader的寫操作,延時不能太久。

符合以上條件的節點準確的說應該是“同步中的(in sync)”,而不是模糊的說是“活着的”或是“失敗的”。Leader會追蹤所有“同步中”的節點,一旦一個down掉了,或是卡住了,或是延時太久,leader就會把它移除。至於延時多久算是“太久”,是由參數replica.lag.max.messages決定的,怎樣算是卡住了,怎是由參數replica.lag.time.max.ms決定的。

只有當消息被所有的副本加入到日誌中時,纔算是“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掉時,必須及時作出反應。可以有以下兩種選擇:

  • 等待ISR中的任何一個節點恢復並擔任leader。
  • 選擇所有節點中(不只是ISR)第一個恢復的節點作爲leader.

這是一個在可用性和連續性之間的權衡。如果等待ISR中的節點恢復,一旦ISR中的節點不起來或者數據丟失了,那集羣就永遠恢復不了了。如果等待ISR意外的節點恢復,這個節點的數據就會被作爲線上數據,有可能和真實的數據有所出入,因爲有些數據它可能還沒同步到。Kafka目前選擇了第二種策略,在未來的版本中將使這個策略的選擇可配置,可以根據場景靈活的選擇。
這種窘境不只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.它們都實現了同一個接口:

class Producer {
/* 將消息發送到指定分區 */
publicvoid send(kafka.javaapi.producer.ProducerData<K,V> producerData);
/* 批量發送一批消息 */
publicvoid send(java.util.List<kafka.javaapi.producer.ProducerData<K,V>> producerData);
/* 關閉producer */
publicvoid close();
}

Producer API提供了以下功能:

  • 可以將多個消息緩存到本地隊列裏,然後異步的批量發送到broker,可以通過參數producer.type=async做到。緩存的大小可以通過一些參數指定:queue.time和batch.size。一個後臺線程((kafka.producer.async.ProducerSendThread)從隊列中取出數據並讓kafka.producer.EventHandler將消息發送到broker,也可以通過參數event.handler定製handler,在producer端處理數據的不同的階段註冊處理器,比如可以對這一過程進行日誌追蹤,或進行一些監控。只需實現kafka.producer.async.CallbackHandler接口,並在callback.handler中配置。
  • 自己編寫Encoder來序列化消息,只需實現下面這個接口。默認的Encoder是kafka.serializer.DefaultEncoder。
    interface Encoder {
    public Message toMessage(T data);
    }
  • 提供了基於Zookeeper的broker自動感知能力,可以通過參數zk.connect實現。如果不使用Zookeeper,也可以使用broker.list參數指定一個靜態的brokers列表,這樣消息將被隨機的發送到一個broker上,一旦選中的broker失敗了,消息發送也就失敗了。
  • 通過分區函數kafka.producer.Partitioner類對消息分區。
    interface Partitioner {
    int partition(T key, int numPartitions);
    }
    分區函數有兩個參數:key和可用的分區數量,從分區列表中選擇一個分區並返回id。默認的分區策略是hash(key)%numPartitions.如果key是null,就隨機的選擇一個。可以通過參數partitioner.class定製分區函數。

KafKa Consumer APIs

Consumer API有兩個級別。低級別的和一個指定的broker保持連接,並在接收完消息後關閉連接,這個級別是無狀態的,每次讀取消息都帶着offset。
高級別的API隱藏了和brokers連接的細節,在不必關心服務端架構的情況下和服務端通信。還可以自己維護消費狀態,並可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達式。

低級別的API:

class SimpleConsumer {
/*向一個broker發送讀取請求並得到消息集 */
public ByteBufferMessageSet fetch(FetchRequest request);
/*向一個broker發送讀取請求並得到一個相應集 */
public MultiFetchResponse multifetch(List<FetchRequest> fetches);
/**
* 得到指定時間之前的offsets
* 返回值是offsets列表,以倒序排序
* @param time: 時間,毫秒,
* 如果指定爲OffsetRequest$.MODULE$.LATIEST_TIME(), 得到最新的offset.
* 如果指定爲OffsetRequest$.MODULE$.EARLIEST_TIME(),得到最老的offset.
*/
publiclong[] getOffsetsBefore(String topic, int partition, long time, int maxNumOffsets);
}

低級別的API是高級別API實現的基礎,也是爲了一些對維持消費狀態有特殊需求的場景,比如Hadoop consumer這樣的離線consumer。

高級別的API:

/* 創建連接 */
ConsumerConnector connector = Consumer.create(consumerConfig);
interface ConsumerConnector {
/**
* 這個方法可以得到一個流的列表,每個流都是MessageAndMetadata的迭代,通過MessageAndMetadata可以拿到消息和其他的元數據(目前之後topic)
* Input: a map of <topic, #streams>
* Output: a map of <topic, list of message streams>
*/
public Map<String,List<KafkaStream>> createMessageStreams(Map<String,Int> topicCountMap);
/**
* 你也可以得到一個流的列表,它包含了符合TopicFiler的消息的迭代,
* 一個TopicFilter是一個封裝了白名單或黑名單的正則表達式。
*/
public List<KafkaStream> createMessageStreamsByFilter(
TopicFilter topicFilter, int numStreams);
/* 提交目前消費到的offset */
public commitOffsets()
/* 關閉連接 */
public shutdown()
}

消息和日誌

消息由一個固定長度的頭部和可變長度的字節數組組成。頭部包含了一個版本號和CRC32校驗碼。

/**
* 具有N個字節的消息的格式如下
*
* 如果版本號是0
*
* 1. 1個字節的 "magic" 標記
*
* 2. 4個字節的CRC32校驗碼
*
* 3. N - 5個字節的具體信息
*
* 如果版本號是1
*
* 1. 1個字節的 "magic" 標記
*
* 2.1個字節的參數允許標註一些附加的信息比如是否壓縮了,解碼類型等
*
* 3.4個字節的CRC32校驗碼
*
* 4. N - 6 個字節的具體信息
*
*/

日誌一個叫做“my_topic”且有兩個分區的的topic,它的日誌有兩個文件夾組成,my_topic_0和my_topic_1,每個文件夾裏放着具體的數據文件,每個數據文件都是一系列的日誌實體,每個日誌實體有一個4個字節的整數N標註消息的長度,後邊跟着N個字節的消息。每個消息都可以由一個64位的整數offset標註,offset標註了這條消息在發送到這個分區的消息流中的起始位置。每個日誌文件的名稱都是這個文件第一條日誌的offset.所以第一個日誌文件的名字就是00000000000.kafka.所以每相鄰的兩個文件名字的差就是一個數字S,S差不多就是配置文件中指定的日誌文件的最大容量。

消息的格式都由一個統一的接口維護,所以消息可以在producer,broker和consumer之間無縫的傳遞。存儲在硬盤上的消息格式如下所示:

  • 消息長度: 4 bytes (value: 1+4+n)
  • 版本號: 1 byte
  • CRC校驗碼: 4 bytes
  • 具體的消息: n bytes

在這裏插入圖片描述
寫操作
消息被不斷的追加到最後一個日誌的末尾,當日志的大小達到一個指定的值時就會產生一個新的文件。對於寫操作有兩個參數,一個規定了消息的數量達到這個值時必須將數據刷新到硬盤上,另外一個規定了刷新到硬盤的時間間隔,這對數據的持久性是個保證,在系統崩潰的時候只會丟失一定數量的消息或者一個時間段的消息。

讀操作
讀操作需要兩個參數:一個64位的offset和一個S字節的最大讀取量。S通常比單個消息的大小要大,但在一些個別消息比較大的情況下,S會小於單個消息的大小。這種情況下讀操作會不斷重試,每次重試都會將讀取量加倍,直到讀取到一個完整的消息。可以配置單個消息的最大值,這樣服務器就會拒絕大小超過這個值的消息。也可以給客戶端指定一個嘗試讀取的最大上限,避免爲了讀到一個完整的消息而無限次的重試。

在實際執行讀取操縱時,首先需要定位數據所在的日誌文件,然後根據offset計算出在這個日誌中的offset(前面的的offset是整個分區的offset),然後在這個offset的位置進行讀取。定位操作是由二分查找法完成的,Kafka在內存中爲每個文件維護了offset的範圍。

下面是發送給consumer的結果的格式:

MessageSetSend (fetch result)

total length     : 4 bytes
error code       : 2 bytes
message 1        : x bytes
...
message n        : x bytes
MultiMessageSetSend (multiFetch result)

total length       : 4 bytes
error code         : 2 bytes
messageSetSend 1
...
messageSetSend n

刪除
日誌管理器允許定製刪除策略。目前的策略是刪除修改時間在N天之前的日誌(按時間刪除),也可以使用另外一個策略:保留最後的N GB數據的策略(按大小刪除)。爲了避免在刪除時阻塞讀操作,採用了copy-on-write形式的實現,刪除操作進行時,讀取操作的二分查找功能實際是在一個靜態的快照副本上進行的,這類似於Java的CopyOnWriteArrayList。

可靠性保證
日誌文件有一個可配置的參數M,緩存超過這個數量的消息將被強行刷新到硬盤。一個日誌矯正線程將循環檢查最新的日誌文件中的消息確認每個消息都是合法的。合法的標準爲:所有文件的大小的和最大的offset小於日誌文件的大小,並且消息的CRC32校驗碼與存儲在消息實體中的校驗碼一致。如果在某個offset發現不合法的消息,從這個offset到下一個合法的offset之間的內容將被移除。

有兩種情況必須考慮:
1,當發生崩潰時有些數據塊未能寫入。
2,寫入了一些空白數據塊。第二種情況的原因是,對於每個文件,操作系統都有一個inode(inode是指在許多“類Unix文件系統”中的一種數據結構。每個inode保存了文件系統中的一個文件系統對象,包括文件、目錄、大小、設備文件、socket、管道, 等等),但無法保證更新inode和寫入數據的順序,當inode保存的大小信息被更新了,但寫入數據時發生了崩潰,就產生了空白數據塊。CRC校驗碼可以檢查這些塊並移除,當然因爲崩潰而未寫入的數據塊也就丟失了。

參考資料:
Kafka入門經典教程

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章