常量時(shí)間的操作效率

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

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

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

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

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

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

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

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

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

zero copy

Broker維護(hù)的消息日志僅僅是一些目錄文件，消息集以固定隊(duì)的格式寫入到日志文件中，這個(gè)格式producer和consumer是共享的，這使得Kafka可以一個(gè)很重要的點(diǎn)進(jìn)行優(yōu)化：消息在網(wǎng)絡(luò)上的傳遞?，F(xiàn)代的unix操作系統(tǒng)提供了高性能的將數(shù)據(jù)從頁面緩存發(fā)送到socket的系統(tǒng)函數(shù)，在linux中，這個(gè)函數(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)化了性能。
在一個(gè)多consumers的場景里，數(shù)據(jù)僅僅被拷貝到頁面緩存一次而不是每次消費(fèi)消息的時(shí)候都重復(fù)的進(jìn)行拷貝。這使得消息以近乎網(wǎng)絡(luò)帶寬的速率發(fā)送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因?yàn)閿?shù)據(jù)都是從頁面緩存中直接發(fā)送到網(wǎng)絡(luò)上去了。
這篇文章詳細(xì)介紹了sendfile和zero-copy技術(shù)在Java方面的應(yīng)用。
數(shù)據(jù)壓縮
很多時(shí)候，性能的瓶頸并非CPU或者硬盤而是網(wǎng)絡(luò)帶寬，對(duì)于需要在數(shù)據(jù)中心之間傳送大量數(shù)據(jù)的應(yīng)用更是如此。當(dāng)然用戶可以在沒有Kafka支持的情況下各自壓縮自己的消息，但是這將導(dǎo)致較低的壓縮率，因?yàn)橄啾扔趯⑾为?dú)壓縮，將大量文件壓縮在一起才能起到最好的壓縮效果。
Kafka采用了端到端的壓縮：因?yàn)橛小跋⒓钡母拍睿蛻舳说南⒖梢砸黄鸨粔嚎s后送到服務(wù)端，并以壓縮后的格式寫入日志文件，以壓縮的格式發(fā)送到consumer，消息從producer發(fā)出到consumer拿到都被是壓縮的，只有在consumer使用的時(shí)候才被解壓縮，所以叫做“端到端的壓縮”。
Kafka支持GZIP和Snappy壓縮協(xié)議。更詳細(xì)的內(nèi)容可以查看這里。

Kafka Producer

消息發(fā)送

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

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

異步發(fā)送

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

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

Kafka Consumer

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

推還是拉？

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

消費(fèi)狀態(tài)跟蹤

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

離線處理消息

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

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

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

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

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

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

Leader的選擇

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

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

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

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

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

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

副本管理

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

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

Kafka Producer APIs

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

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

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

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

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

分區(qū)函數(shù)有兩個(gè)參數(shù)：key和可用的分區(qū)數(shù)量，從分區(qū)列表中選擇一個(gè)分區(qū)并返回id。默認(rèn)的分區(qū)策略是hash(key)%numPartitions.如果key是null,就隨機(jī)的選擇一個(gè)。可以通過參數(shù)partitioner.class定制分區(qū)函數(shù)。

KafKa Consumer APIs

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

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

低級(jí)別的API

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

低級(jí)別的API是高級(jí)別API實(shí)現(xiàn)的基礎(chǔ)，也是為了一些對(duì)維持消費(fèi)狀態(tài)有特殊需求的場景，比如Hadoop consumer這樣的離線consumer。

高級(jí)別的API

/* 創(chuàng)建連接 */ConsumerConnector connector = Consumer.create(consumerConfig); interface ConsumerConnector { /**  * 這個(gè)方法可以得到一個(gè)流的列表，每個(gè)流都是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); /**  * 你也可以得到一個(gè)流的列表，它包含了符合TopicFiler的消息的迭代， * 一個(gè)TopicFilter是一個(gè)封裝了白名單或黑名單的正則表達(dá)式。 */public List<KafkaStream> createMessageStreamsByFilter(  TopicFilter topicFilter, int numStreams); /* 提交目前消費(fèi)到的offset */public commitOffsets() /* 關(guān)閉連接 */public shutdown() } 

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

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

消息格式

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

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

日志

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

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

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

寫操作

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

讀操作

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

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

刪除

日志管理器允許定制刪除策略。目前的策略是刪除修改時(shí)間在N天之前的日志（按時(shí)間刪除），也可以使用另外一個(gè)策略：保留最后的N GB數(shù)據(jù)的策略(按大小刪除)。為了避免在刪除時(shí)阻塞讀操作，采用了copy-on-write形式的實(shí)現(xiàn)，刪除操作進(jìn)行時(shí)，讀取操作的二分查找功能實(shí)際是在一個(gè)靜態(tài)的快照副本上進(jìn)行的，這類似于Java的CopyOnWriteArrayList。

可靠性保證

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

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