【Kafka官方文檔翻譯】5.4.5. 消費(fèi)者

原文地址:https://kafka.apache.org/0101/documentation.html#theconsumer

消費(fèi)者通過從主分區(qū)的服務(wù)器獲取數(shù)據(jù)進(jìn)行消費(fèi)悍募。消費(fèi)者指定每次請求時(shí)日志的偏移量良漱,然后從這個(gè)位置開啟批量獲取數(shù)據(jù)。消費(fèi)者對位移量有絕對的控制權(quán)蒸甜,這樣消費(fèi)者可以重新設(shè)置位移位置倒慧,并在有需要的時(shí)重新消費(fèi)柳洋。

推送 vs 拉取

一個(gè)基本的問題是走敌,我們在考慮消費(fèi)者是主動(dòng)從服務(wù)器那里拉去數(shù)據(jù)惯豆,還是服務(wù)器應(yīng)該主動(dòng)推送數(shù)據(jù)到消費(fèi)者端蠢熄。在這方面跪解,kafka和傳統(tǒng)的消息吸引設(shè)計(jì)一樣,生產(chǎn)者推送消息到服務(wù)器签孔,消費(fèi)者從服務(wù)器拉去消息叉讥。在一些日志中心系統(tǒng),像 ScribeApache Flume饥追,使用一種特殊的推送流數(shù)據(jù)推送機(jī)制图仓,這些方式都有利有弊,但是但绕,在一個(gè)基于推送方式消息系統(tǒng)救崔,很難處理大量的消費(fèi)者,因?yàn)榉?wù)器需要控制數(shù)據(jù)的傳輸速率捏顺。目標(biāo)是為了讓消費(fèi)者盡可能多消費(fèi)數(shù)據(jù)六孵;不幸的是,在一個(gè)推送系統(tǒng)幅骄,這意味著消費(fèi)者往往被消息淹沒劫窒,如果消費(fèi)率低于生產(chǎn)速度(例如密集的服務(wù)攻擊)〔鹱基于拉取的系統(tǒng)往往比較優(yōu)雅些主巍,消息處理只是落后,消費(fèi)者在后面盡可能趕上挪凑。
  使用基于拉取方式的系統(tǒng)還有一個(gè)好處就是容易匯集批量數(shù)據(jù)后發(fā)給消費(fèi)者孕索。基于推送的系統(tǒng)岖赋,要么馬上發(fā)送請求檬果,要么匯總數(shù)據(jù)后再發(fā)送,而不光下游的消費(fèi)者是否能夠處理得上唐断。如果為了進(jìn)一步降低延遲,這會(huì)導(dǎo)致緩存還沒有結(jié)束時(shí)就傳輸單條數(shù)據(jù)過去杭抠,這樣很浪費(fèi)脸甘。基于拉的方式可以從當(dāng)前日志位置拉去可用的消息(或者根據(jù)配置的大小)偏灿。這樣能在沒有引入不必要的延遲的情況下丹诀,獲取到比較好的批處理性能。
  基于拉取方式的系統(tǒng)不足的地方是如果沒有任何數(shù)據(jù),消費(fèi)者就要循環(huán)檢測铆遭,使用空輪詢的繁忙檢測方式等候數(shù)據(jù)到來硝桩。為了避免這一點(diǎn),我們可以設(shè)置拉請求的參數(shù)枚荣,允許消費(fèi)者請求在“長輪詢”時(shí)阻塞碗脊,直到數(shù)據(jù)到達(dá)。
  你可以想象一些其他從端到端的一些可能性設(shè)計(jì)橄妆。生產(chǎn)者把記錄寫入到本地日志中衙伶,服務(wù)器將從消費(fèi)者拉取的數(shù)據(jù)中拉取。一種類似的儲存和轉(zhuǎn)發(fā)的生產(chǎn)者模型經(jīng)常被提議害碾。這雖然挺有趣的矢劲,但不適合有成千上萬生產(chǎn)者的情況。在我們大規(guī)模運(yùn)行數(shù)據(jù)儲存系統(tǒng)的經(jīng)驗(yàn)來看慌随,成千上萬的磁盤跨越多個(gè)應(yīng)用并不讓系統(tǒng)更為可靠芬沉,操作起來將會(huì)是一個(gè)噩夢。在實(shí)踐中阁猜,我們發(fā)現(xiàn)可以創(chuàng)建具有很強(qiáng)壯的SLAs保障的花嘶,大規(guī)模的管道,并且不需要提供者有持久化能力蹦漠。

消費(fèi)位置

令人驚訝的是椭员,跟蹤已消耗的內(nèi)容是消息傳遞系統(tǒng)的關(guān)鍵性能點(diǎn)之一。
  大部分的消息系統(tǒng)在服務(wù)器端記錄哪些消息被消費(fèi)的元數(shù)據(jù)信息笛园。那就是隘击,消息被發(fā)送給消費(fèi)者時(shí),服務(wù)器要么在本地馬上記錄日志研铆,要么等待消費(fèi)者反饋后記錄埋同。這樣的話相當(dāng)不直觀,事實(shí)上棵红,對于一臺服務(wù)器凶赁,很難理清楚這個(gè)狀態(tài)到底去哪里了。因?yàn)樵诖蟛糠值南Υ嫦到y(tǒng)中逆甜,數(shù)據(jù)結(jié)構(gòu)很難被擴(kuò)展虱肄,這也依賴于編程的語義,如果服務(wù)器知道消息被消費(fèi)后可以馬上刪除交煞,那么就可以維持比較小的數(shù)據(jù)集咏窿。
  碰巧不太明顯的是,讓服務(wù)器和消費(fèi)者對已經(jīng)消費(fèi)的數(shù)據(jù)達(dá)成一致并不是一件簡單的事情素征。如果服務(wù)器在每次數(shù)據(jù)分發(fā)出去后集嵌,馬上標(biāo)記消息已經(jīng)被消費(fèi)了萝挤,如果消費(fèi)者處理消息失敗了(例如宕機(jī)了),那么消息可能會(huì)丟失根欧。為了解決這個(gè)問題怜珍,很多消息系統(tǒng)添加了反饋機(jī)制,用于標(biāo)記消息已經(jīng)被發(fā)送凤粗,而不是被消費(fèi)酥泛,服務(wù)器等待消費(fèi)者發(fā)送一個(gè)反饋來確認(rèn)消息已經(jīng)被消費(fèi)。這個(gè)策略解決消息丟失的問題侈沪,但是同時(shí)也引發(fā)新的問題揭璃。首先,如果消費(fèi)者已經(jīng)消費(fèi)了記錄亭罪,但是在反饋時(shí)失敗瘦馍,則有可能重復(fù)消費(fèi)兩次。其次应役,是多一個(gè)來回的性能損耗情组,現(xiàn)在服務(wù)器就要為每個(gè)消息保存不同的狀態(tài)(先鎖定,這樣不會(huì)發(fā)送第二次箩祥,然后標(biāo)記為永久消費(fèi)后院崇,才能把它刪除)。還有些麻煩的問題需要處理袍祖,比如消息被發(fā)送了底瓣,但是從來沒有接受到反饋。
  kafka使用不一樣的處理方式蕉陋,主題被劃分成一系列有序的分區(qū)集合捐凭,每個(gè)分區(qū)在一個(gè)時(shí)刻僅被訂閱分組中的一個(gè)消費(fèi)者消費(fèi)。這意味這每個(gè)消費(fèi)者在一個(gè)分區(qū)位置就只是一個(gè)數(shù)值凳鬓,用于記錄下一次消息要被消費(fèi)的位置茁肠。這意味著記錄消費(fèi)者狀態(tài)的代價(jià)非常小,只是每個(gè)分區(qū)一個(gè)數(shù)值缩举。這個(gè)狀態(tài)可以定期做檢查點(diǎn)垦梆,這使等價(jià)的消息反饋代價(jià)非常小。
  這個(gè)方案還有另外的好處仅孩,消費(fèi)者可以優(yōu)雅地重新指定一個(gè)舊的位移位置托猩,并重新消費(fèi)數(shù)據(jù)。這個(gè)和通常的隊(duì)列觀念有點(diǎn)相悖杠氢,但是對很多消費(fèi)者來說是一個(gè)很重要的特性站刑。例如,如果消費(fèi)代碼有bug鼻百,并且在一些消息被消費(fèi)后發(fā)現(xiàn)绞旅,一旦bug被修復(fù),消費(fèi)者可以重新使用這些消息温艇。

離線數(shù)據(jù)加載

可擴(kuò)展的持久性儲存能力因悲,使得消費(fèi)者能定期批量把數(shù)據(jù)導(dǎo)入到離線系統(tǒng)中,如:Hadoop 或關(guān)系型數(shù)據(jù)倉庫勺爱。
  在hadoop的例子中晃琳,我們通過把數(shù)據(jù)分發(fā)到獨(dú)立的任務(wù)集中進(jìn)行并行處理,每個(gè)的單位是按服務(wù)器/主題/分區(qū)琐鲁,這樣可以允許很好的并發(fā)數(shù)據(jù)加載處理卫旱。Hadoop 提供任務(wù)管理,任務(wù)可以在失敗四重新啟動(dòng)围段,而不用擔(dān)心會(huì)重復(fù)處理數(shù)據(jù)——只需要簡單從他們原來處理的位置重新開始顾翼。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市奈泪,隨后出現(xiàn)的幾起案子适贸,更是在濱河造成了極大的恐慌,老刑警劉巖涝桅,帶你破解...
    沈念sama閱讀 211,743評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件拜姿,死亡現(xiàn)場離奇詭異,居然都是意外死亡冯遂,警方通過查閱死者的電腦和手機(jī)蕊肥,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,296評論 3 385
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來蛤肌,“玉大人壁却,你說我怎么就攤上這事⊙岸ǎ” “怎么了儒洛?”我有些...
    開封第一講書人閱讀 157,285評論 0 348
  • 文/不壞的土叔 我叫張陵,是天一觀的道長狼速。 經(jīng)常有香客問我琅锻,道長,這世上最難降的妖魔是什么向胡? 我笑而不...
    開封第一講書人閱讀 56,485評論 1 283
  • 正文 為了忘掉前任恼蓬,我火速辦了婚禮,結(jié)果婚禮上僵芹,老公的妹妹穿的比我還像新娘处硬。我一直安慰自己,他們只是感情好拇派,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,581評論 6 386
  • 文/花漫 我一把揭開白布荷辕。 她就那樣靜靜地躺著凿跳,像睡著了一般。 火紅的嫁衣襯著肌膚如雪疮方。 梳的紋絲不亂的頭發(fā)上控嗜,一...
    開封第一講書人閱讀 49,821評論 1 290
  • 那天,我揣著相機(jī)與錄音骡显,去河邊找鬼疆栏。 笑死,一個(gè)胖子當(dāng)著我的面吹牛惫谤,可吹牛的內(nèi)容都是我干的壁顶。 我是一名探鬼主播,決...
    沈念sama閱讀 38,960評論 3 408
  • 文/蒼蘭香墨 我猛地睜開眼溜歪,長吁一口氣:“原來是場噩夢啊……” “哼若专!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起痹愚,我...
    開封第一講書人閱讀 37,719評論 0 266
  • 序言:老撾萬榮一對情侶失蹤富岳,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后拯腮,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體窖式,經(jīng)...
    沈念sama閱讀 44,186評論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,516評論 2 327
  • 正文 我和宋清朗相戀三年动壤,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了萝喘。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,650評論 1 340
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡琼懊,死狀恐怖阁簸,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情哼丈,我是刑警寧澤启妹,帶...
    沈念sama閱讀 34,329評論 4 330
  • 正文 年R本政府宣布,位于F島的核電站醉旦,受9級特大地震影響饶米,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜车胡,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,936評論 3 313
  • 文/蒙蒙 一檬输、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧匈棘,春花似錦丧慈、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,757評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽鹃愤。三九已至,卻和暖如春笑旺,著一層夾襖步出監(jiān)牢的瞬間昼浦,已是汗流浹背馍资。 一陣腳步聲響...
    開封第一講書人閱讀 31,991評論 1 266
  • 我被黑心中介騙來泰國打工筒主, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人鸟蟹。 一個(gè)月前我還...
    沈念sama閱讀 46,370評論 2 360
  • 正文 我出身青樓乌妙,卻偏偏與公主長得像,于是被迫代替她去往敵國和親建钥。 傳聞我的和親對象是個(gè)殘疾皇子藤韵,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,527評論 2 349

推薦閱讀更多精彩內(nèi)容