常量時間的操作效率

在大多數(shù)的消息系統(tǒng)中，數(shù)據(jù)持久化的機制往往是為每個cosumer提供一個B樹或者其他的隨機讀寫的數(shù)據(jù)結(jié)構(gòu)。B樹當然是很棒的，但是也帶了一些代價：比如B樹的復(fù)雜度是O(log N)，O(log N)通常被認為就是常量復(fù)雜度了，但對于硬盤操作來說并非如此。磁盤進行一次搜索需要10ms，每個硬盤在同一時間只能進行一次搜索，這樣并發(fā)處理就成了問題。雖然存儲系統(tǒng)使用緩存進行了大量優(yōu)化，但是對于樹結(jié)構(gòu)的性能的觀察結(jié)果卻表明，它的性能往往隨著數(shù)據(jù)的增長而線性下降，數(shù)據(jù)增長一倍，速度就會降低一倍。

直觀的講，對于主要用于日志處理的消息系統(tǒng)，數(shù)據(jù)的持久化可以簡單的通過將數(shù)據(jù)追加到文件中實現(xiàn)，讀的時候從文件中讀就好了。這樣做的好處是讀和寫都是 O(1) 的，并且讀操作不會阻塞寫操作和其他操作。這樣帶來的性能優(yōu)勢是很明顯的，因為性能和數(shù)據(jù)的大小沒有關(guān)系了。

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

之前討論了consumer和producer是怎么工作的，現(xiàn)在來討論一下數(shù)據(jù)傳輸方面。數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級別：

 1.最多一次: 消息不會被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸。
 2.最少一次: 消息不會被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.
 3.精確的一次（Exactly once）:  不會漏傳輸也不會重復(fù)傳輸,每個消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的。

大多數(shù)消息系統(tǒng)聲稱可以做到“精確的一次”，但是仔細閱讀它們的的文檔可以看到里面存在誤導，比如沒有說明當consumer或producer失敗時怎么樣，或者當有多個consumer并行時怎么樣，或?qū)懭胗脖P的數(shù)據(jù)丟失時又會怎么樣。kafka的做法要更先進一些。當發(fā)布消息時，Kafka有一個“committed”的概念，一旦消息被提交了，只要消息被寫入的分區(qū)的所在的副本broker是活動的，數(shù)據(jù)就不會丟失。關(guān)于副本的活動的概念，下節(jié)文檔會討論?，F(xiàn)在假設(shè)broker是不會down的。
如果producer發(fā)布消息時發(fā)生了網(wǎng)絡(luò)錯誤，但又不確定實在提交之前發(fā)生的還是提交之后發(fā)生的，這種情況雖然不常見，但是必須考慮進去，現(xiàn)在Kafka版本還沒有解決這個問題，將來的版本正在努力嘗試解決。
并不是所有的情況都需要“精確的一次”這樣高的級別，Kafka允許producer靈活的指定級別。比如producer可以指定必須等待消息被提交的通知，或者完全的異步發(fā)送消息而不等待任何通知，或者僅僅等待leader聲明它拿到了消息（followers沒有必要）。

現(xiàn)在從consumer的方面考慮這個問題，所有的副本都有相同的日志文件和相同的offset，consumer維護自己消費的消息的offset，如果consumer不會崩潰當然可以在內(nèi)存中保存這個值，當然誰也不能保證這點。如果consumer崩潰了，會有另外一個consumer接著消費消息，它需要從一個合適的offset繼續(xù)處理。這種情況下可以有以下選擇：
 
•consumer可以先讀取消息，然后將offset寫入日志文件中，然后再處理消息。這存在一種可能就是在存儲offset后還沒處理消息就crash了，新的consumer繼續(xù)從這個offset處理，那么就會有些消息永遠不會被處理，這就是上面說的“最多一次”。
•consumer可以先讀取消息，處理消息，最后記錄offset，當然如果在記錄offset之前就crash了，新的consumer會重復(fù)的消費一些消息，這就是上面說的“最少一次”。
•“精確一次”可以通過將提交分為兩個階段來解決：保存了offset后提交一次，消息處理成功之后再提交一次。但是還有個更簡單的做法：將消息的offset和消息被處理后的結(jié)果保存在一起。比如用Hadoop ETL處理消息時，將處理后的結(jié)果和offset同時保存在HDFS中，這樣就能保證消息和offser同時被處理了。

Kafka在提高效率方面做了很大努力。Kafka的一個主要使用場景是處理網(wǎng)站活動日志，吞吐量是非常大的，每個頁面都會產(chǎn)生好多次寫操作。讀方面，假設(shè)每個消息只被消費一次，讀的量的也是很大的，Kafka也盡量使讀的操作更輕量化。

我們之前討論了磁盤的性能問題，線性讀寫的情況下影響磁盤性能問題大約有兩個方面：太多的瑣碎的I/O操作和太多的字節(jié)拷貝。I/O問題發(fā)生在客戶端和服務(wù)端之間，也發(fā)生在服務(wù)端內(nèi)部的持久化的操作中。
消息集（message set）
為了避免這些問題，Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作為處理的單位。以消息集為單位處理消息，比以單個的消息為單位處理，會提升不少性能。Producer把消息集一塊發(fā)送給服務(wù)端，而不是一條條的發(fā)送；服務(wù)端把消息集一次性的追加到日志文件中，這樣減少了瑣碎的I/O操作。consumer也可以一次性的請求一個消息集。
另外一個性能優(yōu)化是在字節(jié)拷貝方面。在低負載的情況下這不是問題，但是在高負載的情況下它的影響還是很大的。為了避免這個問題，Kafka使用了標準的二進制消息格式，這個格式可以在producer,broker和producer之間共享而無需做任何改動。

zero copy

Broker維護的消息日志僅僅是一些目錄文件，消息集以固定隊的格式寫入到日志文件中，這個格式producer和consumer是共享的，這使得Kafka可以一個很重要的點進行優(yōu)化：消息在網(wǎng)絡(luò)上的傳遞。現(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁面緩存發(fā)送到socket的系統(tǒng)函數(shù)，在linux中，這個函數(shù)是sendfile.
為了更好的理解sendfile的好處，我們先來看下一般將數(shù)據(jù)從文件發(fā)送到socket的數(shù)據(jù)流向：
1.操作系統(tǒng)把數(shù)據(jù)從文件拷貝內(nèi)核中的頁緩存中
2.應(yīng)用程序從頁緩存從把數(shù)據(jù)拷貝自己的內(nèi)存緩存中
3.應(yīng)用程序?qū)?shù)據(jù)寫入到內(nèi)核中socket緩存中
4.操作系統(tǒng)把數(shù)據(jù)從socket緩存中拷貝到網(wǎng)卡接口緩存，從這里發(fā)送到網(wǎng)絡(luò)上。

這顯然是低效率的，有4次拷貝和2次系統(tǒng)調(diào)用。Sendfile通過直接將數(shù)據(jù)從頁面緩存發(fā)送網(wǎng)卡接口緩存，避免了重復(fù)拷貝，大大的優(yōu)化了性能。
在一個多consumers的場景里，數(shù)據(jù)僅僅被拷貝到頁面緩存一次而不是每次消費消息的時候都重復(fù)的進行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因為數(shù)據(jù)都是從頁面緩存中直接發(fā)送到網(wǎng)絡(luò)上去了。
這篇文章詳細介紹了sendfile和zero-copy技術(shù)在Java方面的應(yīng)用。
數(shù)據(jù)壓縮
很多時候，性能的瓶頸并非CPU或者硬盤而是網(wǎng)絡(luò)帶寬，對于需要在數(shù)據(jù)中心之間傳送大量數(shù)據(jù)的應(yīng)用更是如此。當然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息，但是這將導致較低的壓縮率，因為相比于將消息單獨壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的壓縮：因為有“消息集”的概念，客戶端的消息可以一起被壓縮后送到服務(wù)端，并以壓縮后的格式寫入日志文件，以壓縮的格式發(fā)送到consumer，消息從producer發(fā)出到consumer拿到都被是壓縮的，只有在consumer使用的時候才被解壓縮，所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協(xié)議。更詳細的內(nèi)容可以查看這里。

Kafka Producer

消息發(fā)送

producer直接將數(shù)據(jù)發(fā)送到broker的leader(主節(jié)點)，不需要在多個節(jié)點進行分發(fā)。為了幫助producer做到這點，所有的Kafka節(jié)點都可以及時的告知:哪些節(jié)點是活動的，目標topic目標分區(qū)的leader在哪。這樣producer就可以直接將消息發(fā)送到目的地了。

客戶端控制消息將被分發(fā)到哪個分區(qū)?？梢酝ㄟ^負載均衡隨機的選擇，或者使用分區(qū)函數(shù)。Kafka允許用戶實現(xiàn)分區(qū)函數(shù)，指定分區(qū)的key，將消息hash到不同的分區(qū)上(當然有需要的話，也可以覆蓋這個分區(qū)函數(shù)自己實現(xiàn)邏輯).比如如果你指定的key是user id，那么同一個用戶發(fā)送的消息都被發(fā)送到同一個分區(qū)上。經(jīng)過分區(qū)之后，consumer就可以有目的的消費某個分區(qū)的消息。

異步發(fā)送

批量發(fā)送可以很有效的提高發(fā)送效率。Kafka producer的異步發(fā)送模式允許進行批量發(fā)送，先將消息緩存在內(nèi)存中，然后一次請求批量發(fā)送出去。這個策略可以配置的，比如可以指定緩存的消息達到某個量的時候就發(fā)出去，或者緩存了固定的時間后就發(fā)送出去（比如100條消息就發(fā)送，或者每5秒發(fā)送一次）。這種策略將大大減少服務(wù)端的I/O次數(shù)。

既然緩存是在producer端進行的，那么當producer崩潰時，這些消息就會丟失。Kafka0.8.1的異步發(fā)送模式還不支持回調(diào)，就不能在發(fā)送出錯時進行處理。Kafka 0.9可能會增加這樣的回調(diào)函數(shù)。見Proposed Producer API.

Kafka Consumer

Kafa consumer消費消息時，向broker發(fā)出"fetch"請求去消費特定分區(qū)的消息。consumer指定消息在日志中的偏移量（offset），就可以消費從這個位置開始的消息。customer擁有了offset的控制權(quán)，可以向后回滾去重新消費之前的消息，這是很有意義的。

推還是拉？

Kafka最初考慮的問題是，customer應(yīng)該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push。在這方面，Kafka遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計：producer將消息推送到broker，consumer從broker拉取消息。
一些消息系統(tǒng)比如Scribe和Apache Flume采用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對于不同消費速率的consumer就不太好處理了。消息系統(tǒng)都致力于讓consumer以最大的速率最快速的消費消息，但不幸的是，push模式下，當broker推送的速率遠大于consumer消費的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統(tǒng)的pull模式。
Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免consumer崩潰而采用較低的推送速率，將可能導致一次只推送較少的消息而造成浪費。Pull模式下，consumer就可以根據(jù)自己的消費能力去決定這些策略。
Pull有個缺點是，如果broker沒有可供消費的消息，將導致consumer不斷在循環(huán)中輪詢，直到新消息到t達。為了避免這點，Kafka有個參數(shù)可以讓consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數(shù)量達到某個特定的量這樣就可以批量發(fā)送)。

消費狀態(tài)跟蹤

對消費消息狀態(tài)的記錄也是很重要的。
大部分消息系統(tǒng)在broker端的維護消息被消費的記錄：一個消息被分發(fā)到consumer后broker就馬上進行標記或者等待customer的通知后進行標記。這樣也可以在消息在消費后立馬就刪除以減少空間占用。
但是這樣會不會有什么問題呢？如果一條消息發(fā)送出去之后就立即被標記為消費過的，一旦consumer處理消息時失敗了（比如程序崩潰）消息就丟失了。為了解決這個問題，很多消息系統(tǒng)提供了另外一個個功能：當消息被發(fā)送出去之后僅僅被標記為已發(fā)送狀態(tài)，當接到consumer已經(jīng)消費成功的通知后才標記為已被消費的狀態(tài)。這雖然解決了消息丟失的問題，但產(chǎn)生了新問題，首先如果consumer處理消息成功了但是向broker發(fā)送響應(yīng)時失敗了，這條消息將被消費兩次。第二個問題時，broker必須維護每條消息的狀態(tài)，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來了，且不說要維護大量的狀態(tài)數(shù)據(jù)，比如如果消息發(fā)送出去但沒有收到消費成功的通知，這條消息將一直處于被鎖定的狀態(tài)，
Kafka采用了不同的策略。Topic被分成了若干分區(qū)，每個分區(qū)在同一時間只被一個consumer消費。這意味著每個分區(qū)被消費的消息在日志中的位置僅僅是一個簡單的整數(shù)：offset。這樣就很容易標記每個分區(qū)消費狀態(tài)就很容易了，僅僅需要一個整數(shù)而已。這樣消費狀態(tài)的跟蹤就很簡單了。
這帶來了另外一個好處：consumer可以把offset調(diào)成一個較老的值，去重新消費老的消息。這對傳統(tǒng)的消息系統(tǒng)來說看起來有些不可思議，但確實是非常有用的，誰規(guī)定了一條消息只能被消費一次呢？consumer發(fā)現(xiàn)解析數(shù)據(jù)的程序有bug，在修改bug后再來解析一次消息，看起來是很合理的額呀！

離線處理消息

高級的數(shù)據(jù)持久化允許consumer每個隔一段時間批量的將數(shù)據(jù)加載到線下系統(tǒng)中比如Hadoop或者數(shù)據(jù)倉庫。這種情況下，Hadoop可以將加載任務(wù)分拆，拆成每個broker或每個topic或每個分區(qū)一個加載任務(wù)。Hadoop具有任務(wù)管理功能，當一個任務(wù)失敗了就可以重啟而不用擔心數(shù)據(jù)被重新加載，只要從上次加載的位置繼續(xù)加載消息就可以了。

Kafka允許topic的分區(qū)擁有若干副本，這個數(shù)量是可以配置的，你可以為每個topci配置副本的數(shù)量。Kafka會自動在每個個副本上備份數(shù)據(jù)，所以當一個節(jié)點down掉時數(shù)據(jù)依然是可用的。

Kafka的副本功能不是必須的，你可以配置只有一個副本，這樣其實就相當于只有一份數(shù)據(jù)。

創(chuàng)建副本的單位是topic的分區(qū)，每個分區(qū)都有一個leader和零或多個followers.所有的讀寫操作都由leader處理，一般分區(qū)的數(shù)量都比broker的數(shù)量多的多，各分區(qū)的leader均勻的分布在brokers中。所有的followers都復(fù)制leader的日志，日志中的消息和順序都和leader中的一致。flowers向普通的consumer那樣從leader那里拉取消息并保存在自己的日志文件中。
許多分布式的消息系統(tǒng)自動的處理失敗的請求，它們對一個節(jié)點是否
著（alive）”有著清晰的定義。Kafka判斷一個節(jié)點是否活著有兩個條件：
1.節(jié)點必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個節(jié)點的連接。
2.如果節(jié)點是個follower,他必須能及時的同步leader的寫操作，延時不能太久。

符合以上條件的節(jié)點準確的說應(yīng)該是“同步中的（in sync）”，而不是模糊的說是“活著的”或是“失敗的”。Leader會追蹤所有“同步中”的節(jié)點，一旦一個down掉了，或是卡住了，或是延時太久，leader就會把它移除。至于延時多久算是“太久”，是由參數(shù)replica.lag.max.messages決定的，怎樣算是卡住了，怎是由參數(shù)replica.lag.time.max.ms決定的。
只有當消息被所有的副本加入到日志中時，才算是“committed”，只有committed的消息才會發(fā)送給consumer，這樣就不用擔心一旦leader down掉了消息會丟失。Producer也可以選擇是否等待消息被提交的通知，這個是由參數(shù)request.required.acks決定的。

Kafka保證只要有一個“同步中”的節(jié)點，“committed”的消息就不會丟失。

Leader的選擇

Kafka的核心是日志文件，日志文件在集群中的同步是分布式數(shù)據(jù)系統(tǒng)最基礎(chǔ)的要素。

如果leaders永遠不會down的話我們就不需要followers了！一旦leader down掉了，需要在followers中選擇一個新的leader.但是followers本身有可能延時太久或者crash，所以必須選擇高質(zhì)量的follower作為leader.必須保證，一旦一個消息被提交了，但是leader down掉了，新選出的leader必須可以提供這條消息。大部分的分布式系統(tǒng)采用了多數(shù)投票法則選擇新的leader,對于多數(shù)投票法則，就是根據(jù)所有副本節(jié)點的狀況動態(tài)的選擇最適合的作為leader.Kafka并不是使用這種方法。

Kafaka動態(tài)維護了一個同步狀態(tài)的副本的集合（a set of in-sync replicas），簡稱ISR，在這個集合中的節(jié)點都是和leader保持高度一致的，任何一條消息必須被這個集合中的每個節(jié)點讀取并追加到日志中了，才回通知外部這個消息已經(jīng)被提交了。因此這個集合中的任何一個節(jié)點隨時都可以被選為leader.ISR在ZooKeeper中維護。ISR中有f+1個節(jié)點，就可以允許在f個節(jié)點down掉的情況下不會丟失消息并正常提供服。ISR的成員是動態(tài)的，如果一個節(jié)點被淘汰了，當它重新達到“同步中”的狀態(tài)時，他可以重新加入ISR.這種leader的選擇方式是非常快速的，適合kafka的應(yīng)用場景。

一個邪惡的想法：如果所有節(jié)點都down掉了怎么辦？Kafka對于數(shù)據(jù)不會丟失的保證，是基于至少一個節(jié)點是存活的，一旦所有節(jié)點都down了，這個就不能保證了。
實際應(yīng)用中，當所有的副本都down掉時，必須及時作出反應(yīng)?？梢杂幸韵聝煞N選擇:
1.等待ISR中的任何一個節(jié)點恢復(fù)并擔任leader。
2.選擇所有節(jié)點中（不只是ISR）第一個恢復(fù)的節(jié)點作為leader.

這是一個在可用性和連續(xù)性之間的權(quán)衡。如果等待ISR中的節(jié)點恢復(fù)，一旦ISR中的節(jié)點起不起來或者數(shù)據(jù)都是了，那集群就永遠恢復(fù)不了了。如果等待ISR意外的節(jié)點恢復(fù)，這個節(jié)點的數(shù)據(jù)就會被作為線上數(shù)據(jù)，有可能和真實的數(shù)據(jù)有所出入，因為有些數(shù)據(jù)它可能還沒同步到。Kafka目前選擇了第二種策略，在未來的版本中將使這個策略的選擇可配置，可以根據(jù)場景靈活的選擇。

這種窘境不只Kafka會遇到，幾乎所有的分布式數(shù)據(jù)系統(tǒng)都會遇到。

副本管理

以上僅僅以一個topic一個分區(qū)為例子進行了討論，但實際上一個Kafka將會管理成千上萬的topic分區(qū).Kafka盡量的使所有分區(qū)均勻的分布到集群所有的節(jié)點上而不是集中在某些節(jié)點上，另外主從關(guān)系也盡量均衡這樣每個幾點都會擔任一定比例的分區(qū)的leader.

優(yōu)化leader的選擇過程也是很重要的，它決定了系統(tǒng)發(fā)生故障時的空窗期有多久。Kafka選擇一個節(jié)點作為“controller”,當發(fā)現(xiàn)有節(jié)點down掉的時候它負責在游泳分區(qū)的所有節(jié)點中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區(qū)節(jié)點的主從關(guān)系。如果controller down掉了，活著的節(jié)點中的一個會備切換為新的controller.

Kafka Producer APIs

Procuder API有兩種：kafka.producer.SyncProducer和kafka.producer.async.AsyncProducer.它們都實現(xiàn)了同一個接口：

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

Producer API提供了以下功能：

1.可以將多個消息緩存到本地隊列里，然后異步的批量發(fā)送到broker，可以通過參數(shù)producer.type=async做到。緩存的大小可以通過一些參數(shù)指定：queue.time和batch.size。一個后臺線程（(kafka.producer.async.ProducerSendThread）從隊列中取出數(shù)據(jù)并讓kafka.producer.EventHandler將消息發(fā)送到broker，也可以通過參數(shù)event.handler定制handler，在producer端處理數(shù)據(jù)的不同的階段注冊處理器，比如可以對這一過程進行日志追蹤，或進行一些監(jiān)控。只需實現(xiàn)kafka.producer.async.CallbackHandler接口，并在callback.handler中配置。

2.自己編寫Encoder來序列化消息，只需實現(xiàn)下面這個接口。默認的Encoder是kafka.serializer.DefaultEncoder。

3.提供了基于Zookeeper的broker自動感知能力，可以通過參數(shù)zk.connect實現(xiàn)。如果不使用Zookeeper，也可以使用broker.list參數(shù)指定一個靜態(tài)的brokers列表，這樣消息將被隨機的發(fā)送到一個broker上，一旦選中的broker失敗了，消息發(fā)送也就失敗了。

4.通過分區(qū)函數(shù)kafka.producer.Partitioner類對消息分區(qū)。

分區(qū)函數(shù)有兩個參數(shù)：key和可用的分區(qū)數(shù)量，從分區(qū)列表中選擇一個分區(qū)并返回id。默認的分區(qū)策略是hash(key)%numPartitions.如果key是null,就隨機的選擇一個?？梢酝ㄟ^參數(shù)partitioner.class定制分區(qū)函數(shù)。

KafKa Consumer APIs

Consumer API有兩個級別。低級別的和一個指定的broker保持連接，并在接收完消息后關(guān)閉連接，這個級別是無狀態(tài)的，每次讀取消息都帶著offset。

高級別的API隱藏了和brokers連接的細節(jié)，在不必關(guān)心服務(wù)端架構(gòu)的情況下和服務(wù)端通信。還可以自己維護消費狀態(tài)，并可以通過一些條件指定訂閱特定的topic,比如白名單黑名單或者正則表達式。

低級別的API

class SimpleConsumer { /*向一個broker發(fā)送讀取請求并得到消息集 */public ByteBufferMessageSet fetch(FetchRequest request); /*向一個broker發(fā)送讀取請求并得到一個相應(yīng)集 */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實現(xiàn)的基礎(chǔ)，也是為了一些對維持消費狀態(tài)有特殊需求的場景，比如Hadoop consumer這樣的離線consumer。

高級別的API

/* 創(chuàng)建連接 */ConsumerConnector connector = Consumer.create(consumerConfig); interface ConsumerConnector { /**  * 這個方法可以得到一個流的列表，每個流都是MessageAndMetadata的迭代，通過MessageAndMetadata可以拿到消息和其他的元數(shù)據(jù)（目前之后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() /* 關(guān)閉連接 */public shutdown() } 

這個API圍繞著由KafkaStream實現(xiàn)的迭代器展開，每個流代表一系列從一個或多個分區(qū)多和broker上匯聚來的消息，每個流由一個線程處理，所以客戶端可以在創(chuàng)建的時候通過參數(shù)指定想要幾個流。一個流是多個分區(qū)多個broker的合并，但是每個分區(qū)的消息只會流向一個流。

每調(diào)用一次createMessageStreams都會將consumer注冊到topic上，這樣consumer和brokers之間的負載均衡就會進行調(diào)整。API鼓勵每次調(diào)用創(chuàng)建更多的topic流以減少這種調(diào)整。createMessageStreamsByFilter方法注冊監(jiān)聽可以感知新的符合filter的tipic。

消息格式

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

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

日志

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

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

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

寫操作

消息被不斷的追加到最后一個日志的末尾，當日志的大小達到一個指定的值時就會產(chǎn)生一個新的文件。對于寫操作有兩個參數(shù)，一個規(guī)定了消息的數(shù)量達到這個值時必須將數(shù)據(jù)刷新到硬盤上，另外一個規(guī)定了刷新到硬盤的時間間隔，這對數(shù)據(jù)的持久性是個保證，在系統(tǒng)崩潰的時候只會丟失一定數(shù)量的消息或者一個時間段的消息。

讀操作

讀操作需要兩個參數(shù)：一個64位的offset和一個S字節(jié)的最大讀取量。S通常比單個消息的大小要大，但在一些個別消息比較大的情況下，S會小于單個消息的大小。這種情況下讀操作會不斷重試，每次重試都會將讀取量加倍，直到讀取到一個完整的消息?？梢耘渲脝蝹€消息的最大值，這樣服務(wù)器就會拒絕大小超過這個值的消息。也可以給客戶端指定一個嘗試讀取的最大上限，避免為了讀到一個完整的消息而無限次的重試。

在實際執(zhí)行讀取操縱時，首先需要定位數(shù)據(jù)所在的日志文件，然后根據(jù)offset計算出在這個日志中的offset(前面的的offset是整個分區(qū)的offset),然后在這個offset的位置進行讀取。定位操作是由二分查找法完成的，Kafka在內(nèi)存中為每個文件維護了offset的范圍。

下面是發(fā)送給consumer的結(jié)果的格式：

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數(shù)據(jù)的策略(按大小刪除)。為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現(xiàn)，刪除操作進行時，讀取操作的二分查找功能實際是在一個靜態(tài)的快照副本上進行的，這類似于Java的CopyOnWriteArrayList。

可靠性保證

日志文件有一個可配置的參數(shù)M，緩存超過這個數(shù)量的消息將被強行刷新到硬盤。一個日志矯正線程將循環(huán)檢查最新的日志文件中的消息確認每個消息都是合法的。合法的標準為：所有文件的大小的和最大的offset小于日志文件的大小，并且消息的CRC32校驗碼與存儲在消息實體中的校驗碼一致。如果在某個offset發(fā)現(xiàn)不合法的消息，從這個offset到下一個合法的offset之間的內(nèi)容將被移除。

有兩種情況必須考慮：1，當發(fā)生崩潰時有些數(shù)據(jù)塊未能寫入。2，寫入了一些空白數(shù)據(jù)塊。第二種情況的原因是，對于每個文件，操作系統(tǒng)都有一個inode（inode是指在許多“類Unix文件系統(tǒng)”中的一種數(shù)據(jù)結(jié)構(gòu)。每個inode保存了文件系統(tǒng)中的一個文件系統(tǒng)對象,包括文件、目錄、大小、設(shè)備文件、socket、管道, 等等），但無法保證更新inode和寫入數(shù)據(jù)的順序，當inode保存的大小信息被更新了，但寫入數(shù)據(jù)時發(fā)生了崩潰，就產(chǎn)生了空白數(shù)據(jù)塊。CRC校驗碼可以檢查這些塊并移除，當然因為崩潰而未寫入的數(shù)據(jù)塊也就丟失了。