導(dǎo)語：疫情期間，為了保障國內(nèi)學(xué)子的正常學(xué)習(xí)進(jìn)度，積極響應(yīng)國家"停工不停學(xué)"的號(hào)召，緊急上線疫情期間專用的"老師極速版"，使廣大師生足不出戶，即可快速便捷的完成線上開課。面對(duì)線上課堂百萬量級(jí)的互動(dòng)消息，如何保證消息的實(shí)時(shí)性和準(zhǔn)確性無疑是一個(gè)技術(shù)挑戰(zhàn)。那么如何解決問題呢？接下來，就和小編一起來看看騰訊云中間件CKafka如何為騰訊課堂百萬級(jí)消息提供技術(shù)支撐。(編輯：中間件小Q妹)

背景

兩年前，騰訊在線教育部就在探索如何實(shí)現(xiàn)架構(gòu)轉(zhuǎn)型。在梳理過騰訊課堂初始技術(shù)架構(gòu)的痛點(diǎn)后，規(guī)劃出架構(gòu)演進(jìn)的三個(gè)重點(diǎn)方向：微服務(wù)、中間件、DevOps。尤其在消息中間件的選取上，從自研Hippo消息隊(duì)列切換到云CKafka。這主要?dú)w于以下幾點(diǎn)原因：

· 實(shí)現(xiàn)技術(shù)棧的統(tǒng)一，降低組件適配成本。

· 使用符合開源標(biāo)準(zhǔn)的組件，便于系統(tǒng)切換優(yōu)秀的開源組件。

· CKafka具備高性能、高可用性和高可靠性的特點(diǎn)：免除復(fù)雜的參數(shù)配置，提供專業(yè)的性能調(diào)優(yōu)；磁盤高可靠，即使服務(wù)器壞盤50%也不影響業(yè)務(wù)；多副本備份，更有多可用區(qū)容災(zāi)方案可選，零感知服務(wù)遷移。

· CKafka提供安全的數(shù)據(jù)保障：提供鑒權(quán)與授權(quán)機(jī)制、主子賬號(hào)等功能，為企業(yè)數(shù)據(jù)做好安全防護(hù)。

在剛剛過去的2019年，騰訊在線教育部已全面實(shí)現(xiàn)了業(yè)務(wù)上云，不僅提升了團(tuán)隊(duì)研發(fā)效率，還實(shí)現(xiàn)了快速交付。同時(shí)，CKafka在消息流處理上的高性能特點(diǎn)得以實(shí)踐驗(yàn)證。

而現(xiàn)在，疫情當(dāng)前，面對(duì)全國千萬師生同時(shí)在線的線上課堂，互動(dòng)消息猛增至百萬級(jí)別，無疑對(duì)在線教育平臺(tái)的穩(wěn)定性提出更高要求。為了保證線上課堂廣大師生的穩(wěn)定互動(dòng)，CKafka作為騰訊課堂的底層消息支撐，在消息的實(shí)時(shí)性和可靠性上提供了更優(yōu)化的技術(shù)方案。

騰訊課堂在線課程頁面

CKafka在騰訊課堂的實(shí)踐

Ckafka在騰訊課堂系統(tǒng)架構(gòu)中的應(yīng)用是非常典型的場(chǎng)景，即消息總線和業(yè)務(wù)解耦。使用了GB帶寬、TB存儲(chǔ)規(guī)格的實(shí)例。我們先來看一下CKafka作為消息總線在騰訊課堂的架構(gòu)中所處的位置，如下圖：

從架構(gòu)圖可知，CKafka處于消息管道的中心位置。同時(shí)接收多個(gè)消息源數(shù)據(jù)，等待下游組件的訂閱消費(fèi)。并利用其自身高分布式、高吞吐、高可靠的特性，實(shí)現(xiàn)流量削峰和業(yè)務(wù)解耦。騰訊課堂中的聊天消息、簽到、舉手、獻(xiàn)花、答題卡等功能都使用了該能力。

在線課堂的業(yè)務(wù)場(chǎng)景不允許出現(xiàn)如消息延遲、數(shù)據(jù)丟失等情況，否則就會(huì)立刻被在線課堂的師生們感知業(yè)務(wù)的不穩(wěn)定，造成不良的用戶體驗(yàn)。我們來假設(shè)一個(gè)場(chǎng)景：老師在課堂發(fā)布一個(gè)問題，學(xué)生們舉手回答問題，如果老師發(fā)出的消息出現(xiàn)延時(shí)或丟失的情況，學(xué)生們就不能收到消息，無法及時(shí)給老師反饋問題答案，線上課堂的互動(dòng)效果就會(huì)很差，嚴(yán)重影響課堂教學(xué)質(zhì)量。

如何避免上述問題呢？我們從CKafka保障消息的實(shí)時(shí)性和可靠性兩方面進(jìn)行闡述。

消息的實(shí)時(shí)性

Apache Kafka架構(gòu)上設(shè)計(jì)的底層數(shù)據(jù)讀寫和存儲(chǔ)是以分區(qū)為最小單位進(jìn)行的。首先來看一下Kafka Topic的生產(chǎn)消費(fèi)模型。

如上圖所示，生產(chǎn)者將數(shù)據(jù)寫入到分布在集群內(nèi)不同節(jié)點(diǎn)的不同分區(qū)上，一個(gè)或多個(gè)消費(fèi)者從多臺(tái)Borker的分區(qū)上消費(fèi)訂閱數(shù)據(jù)。

從這個(gè)模型可知，如果數(shù)據(jù)的讀寫都集中在單個(gè)分區(qū)上，則Topic的的所有壓力都會(huì)集中在該分區(qū)上，從而落到單臺(tái)Broker上面。假設(shè)單臺(tái)機(jī)器能承受的流量是300MB，則此時(shí)以騰訊教育的GB/s的流量規(guī)模，則會(huì)出現(xiàn)消息處理過慢，會(huì)導(dǎo)致消息延時(shí)。那怎么辦呢？此時(shí)就應(yīng)該提升分區(qū)的數(shù)量，提高數(shù)據(jù)處理的并行度，從而將整個(gè)topic的壓力均分到多臺(tái)機(jī)器上。

這時(shí)就會(huì)有一個(gè)疑問，Topic需要多少分區(qū)合適呢？是不是越多的分區(qū)越好呢？

影響分區(qū)數(shù)量的因素

從生產(chǎn)者的角度來看，數(shù)據(jù)向不同的分區(qū)寫入是完全并行的；從消費(fèi)者的角度來看，并發(fā)數(shù)完全取決于分區(qū)的數(shù)量(如果 consumer 數(shù)量大于 分區(qū) 數(shù)量，則必有 consumer 閑置)。因此選取合適的分區(qū)對(duì)于發(fā)揮 CKafka 實(shí)例的性能十分重要。

Topic的分區(qū)數(shù)量是由多種因素決定的，一般可以根據(jù)以下幾個(gè)因素綜合考慮：

· 生產(chǎn)者的峰值帶寬

假設(shè)單機(jī)單partiton的生產(chǎn)消費(fèi)吞吐各自最高為300，峰值生產(chǎn)帶寬是900MB，則單純生產(chǎn)至少需要3個(gè)Partiton。

· 消費(fèi)者的峰值帶寬

有人可能會(huì)覺得消費(fèi)的峰值帶寬應(yīng)該等于生產(chǎn)的峰值帶寬。這樣是不對(duì)的。生產(chǎn)者只會(huì)生產(chǎn)一份數(shù)據(jù)，但是可以有N個(gè)消費(fèi)者消費(fèi)同一份數(shù)據(jù)，則此時(shí)消費(fèi)帶寬=N*生產(chǎn)帶寬。 另外如果是離線計(jì)算，可能會(huì)在某一時(shí)刻，消費(fèi)歷史所有數(shù)據(jù)，此時(shí)消費(fèi)帶寬可能會(huì)遠(yuǎn)遠(yuǎn)高于生產(chǎn)帶寬。 此時(shí)如果Topic只設(shè)計(jì)3個(gè)分區(qū)就有問題了。假設(shè)消費(fèi)峰值帶寬是生產(chǎn)帶寬的2倍。則此時(shí)至少需要6個(gè)分區(qū)。

· 消費(fèi)者的處理能力

假設(shè)創(chuàng)建了6個(gè)分區(qū)。此時(shí)6個(gè)分區(qū)最多只會(huì)有6個(gè)消費(fèi)者，每個(gè)消費(fèi)者最多每秒可以從Kafka Server拉到300MB的數(shù)據(jù)。但是每個(gè)消費(fèi)者因?yàn)檫€需處理業(yè)務(wù)邏輯的關(guān)系，只能消費(fèi)100MB的數(shù)據(jù)，這樣就會(huì)容易導(dǎo)致出現(xiàn)消費(fèi)堆積的情況。 為了增大消費(fèi)能力，則需要多加入消費(fèi)者。因?yàn)镵afka的consumer group機(jī)制里同一個(gè)消費(fèi)組里同一個(gè)分區(qū)只能被一個(gè)消費(fèi)者消費(fèi)。所以，就應(yīng)該增大分區(qū)的數(shù)量。為滿足如上需求，此時(shí)至少需要18個(gè)分區(qū)，18個(gè)消費(fèi)者，才能滿足消費(fèi)需求。

在上面的Case中，分區(qū)數(shù)的設(shè)計(jì)也需要存在一定的冗余，因?yàn)楹芏嗲闆r下，性能是無法達(dá)到最優(yōu)的。所以，分區(qū)數(shù)量需要綜合考慮多個(gè)因素，可以適當(dāng)?shù)亩嘁稽c(diǎn)分區(qū)數(shù)量，以提高實(shí)例的性能。但也不能太大，太大也會(huì)導(dǎo)致一系列的其他問題。

選取合適的分區(qū)數(shù)量

考慮到上面提到的實(shí)際因素，是否有一個(gè)相對(duì)簡(jiǎn)單的判斷方法來設(shè)計(jì)分區(qū)數(shù)量呢？

在理想情況下，可以通過如下公式來判斷分區(qū)的數(shù)目：

Num = max( T/PT , T/CT ) = T / min( PT , CT )

其中，Num 代表分區(qū)數(shù)量，T 代表目標(biāo)吞吐量，PT 代表生產(chǎn)者寫入單個(gè) 分區(qū) 的最大吞吐，CT 代表消費(fèi)者從單個(gè)分區(qū)消費(fèi)的最大吞吐。則分區(qū)數(shù)量應(yīng)該等于 T/PT 和 T/CT 中的較大值。

在實(shí)際情況中，生產(chǎn)者寫入分區(qū)的最大吞吐 PT 的影響因素和批處理的規(guī)模、壓縮算法、確認(rèn)機(jī)制、副本數(shù)等有關(guān)。消費(fèi)者從單個(gè)分區(qū)消費(fèi)的最大吞吐 CT 的影響因素和業(yè)務(wù)邏輯有關(guān)，需要在不同場(chǎng)景下實(shí)測(cè)得出。

通常建議分區(qū)的數(shù)量一定要大于等于消費(fèi)者的數(shù)量來實(shí)現(xiàn)最大并發(fā)。 如果消費(fèi)者數(shù)量為5，則分區(qū)的數(shù)目也應(yīng)該 ≥ 5 的。但需要注意的是：過多的分區(qū)會(huì)導(dǎo)致生產(chǎn)吞吐的降低和選舉耗時(shí)的增加，因此也不建議過多分區(qū)。

提供如下信息供參考：

1. 單個(gè)分區(qū)是可以實(shí)現(xiàn)消息的順序?qū)懭氲摹?/p>

2. 單個(gè)分區(qū)只能被同消費(fèi)者組的單個(gè)消費(fèi)者進(jìn)程消費(fèi)。

3. 單個(gè)消費(fèi)者進(jìn)程可同時(shí)消費(fèi)多個(gè)分區(qū)，即分區(qū)限制了消費(fèi)端的并發(fā)能力。

4. 分區(qū)越多，當(dāng)Leader節(jié)點(diǎn)失效后，其他分區(qū)重新進(jìn)行Leader選舉的耗時(shí)就會(huì)越長。

5. 分區(qū)的數(shù)量是可以動(dòng)態(tài)增加的，只能增加不能減少。但增加會(huì)出現(xiàn)消息 rebalance 的情況。

在上述方法的基礎(chǔ)上，我們還綜合考慮了騰訊課堂的生產(chǎn)消費(fèi)峰值帶寬、消費(fèi)的行為特征和單個(gè)消費(fèi)者的消費(fèi)能力等因素，為其設(shè)計(jì)了合理的分區(qū)數(shù)量，以滿足其對(duì)消息實(shí)時(shí)性的要求。

消息的可靠性

消息的可靠性從不同的角度看是不一樣的。從Apache Kafka自身角度看來，消息的可靠性是消息的可靠存儲(chǔ)。從業(yè)務(wù)的角度來看，消息的可靠性是指消息傳輸、存儲(chǔ)、消費(fèi)的可靠性。

從服務(wù)提供商來看，我們希望消息的可靠性是站在客戶這一邊的，即可靠的傳輸，存儲(chǔ)，消費(fèi)。CKafka在做好可靠性存儲(chǔ)的基礎(chǔ)上，還從配置調(diào)優(yōu)、異常告警等方面盡量做到消息的可靠傳輸和消費(fèi)。

關(guān)于副本

在介紹下面的方案前，我們先聊聊一下副本。為什么要有副本的存在呢?

在分布式的場(chǎng)景下，數(shù)據(jù)損壞和機(jī)械故障是被認(rèn)為常見事件。數(shù)據(jù)副本是指在不同節(jié)點(diǎn)上持久化同一份數(shù)據(jù)，當(dāng)某一個(gè)節(jié)點(diǎn)上存儲(chǔ)的數(shù)據(jù)丟失時(shí)，可以從副本上讀取該數(shù)據(jù)，這是解決分布式系統(tǒng)數(shù)據(jù)丟失問題最為有效的方法。

那么我們來思考下：有多少個(gè)副本的數(shù)據(jù)才是安全的？理論上2個(gè)副本就可以大概率范圍的保證數(shù)據(jù)安全，但是當(dāng)兩個(gè)副本都損壞時(shí)，數(shù)據(jù)也會(huì)丟失，此時(shí)就需要更多的副本，或者需要副本跨可用區(qū)、跨地域分布。當(dāng)然更多的副本就意味著要存儲(chǔ)更多的數(shù)據(jù)，需要更高的成本投入。所以用戶需要在冗余和安全之間權(quán)衡出一種平衡。這也是騰訊云上創(chuàng)建topic需要用戶指定副本數(shù)量的原因，如下圖：

服務(wù)端的可靠性

假設(shè)TopicA有3個(gè)分區(qū)，每個(gè)分區(qū)有三個(gè)副本。來看一下如下的Topic分區(qū)分布示意圖。

如圖所示，三個(gè)分區(qū)和三個(gè)副本均勻的分布在三個(gè)Broker中，每臺(tái)Broker分布了一個(gè)分區(qū)的Leader分區(qū)。從上一節(jié)關(guān)于副本的描述可知，除非所有的Broker在同一時(shí)間掛掉，否則即使同時(shí)掛掉2臺(tái)Borker，服務(wù)也可以正常運(yùn)行。而在我們當(dāng)前的運(yùn)營架構(gòu)中，三臺(tái)broker同時(shí)掛掉的概率微乎其微，當(dāng)然如果真的出現(xiàn)這種情況，那就是整個(gè)機(jī)房掛掉了。

為了避免整個(gè)機(jī)房掛掉的情況，騰訊云Ckafka也可以配置跨機(jī)房容災(zāi)和跨可用區(qū)容災(zāi)，來保證數(shù)據(jù)的可靠性。關(guān)于跨可用區(qū)容災(zāi)相關(guān)的技術(shù)點(diǎn)可以查閱：。

我們可以通過參數(shù)配置來盡可能的保證可靠性傳輸和消費(fèi)，用告警來做兜底策略，讓研發(fā)感知介入處理。下面來看一下生產(chǎn)和消費(fèi)端的參數(shù)調(diào)優(yōu)。

客戶端參數(shù)調(diào)優(yōu)

生產(chǎn)的可靠傳輸，主要來看一下如下三個(gè)配置: ack、retries。

· ack

Kafka producer 的 ack 有 3 種機(jī)制，分別說明如下：

-1：Broker 在 leader 收到數(shù)據(jù)并同步給所有 ISR 中的 follower 后，才應(yīng)答給 Producer 繼續(xù)發(fā)送下一條(批)消息。 這種配置提供了最高的數(shù)據(jù)可靠性，只要有一個(gè)已同步的副本存活就不會(huì)有消息丟失。

0：生產(chǎn)者不等待來自 broker 同步完成的確認(rèn)，繼續(xù)發(fā)送下一條(批)消息。這種配置生產(chǎn)性能最高，但數(shù)據(jù)可靠性最低(當(dāng)服務(wù)器故障時(shí)可能會(huì)有數(shù)據(jù)丟失) 。

1：生產(chǎn)者在 leader 已成功收到的數(shù)據(jù)并得到確認(rèn)后再發(fā)送下一條(批)消息。這種配置是在生產(chǎn)吞吐和數(shù)據(jù)可靠性之間的權(quán)衡(如果leader已死但是尚未復(fù)制，則消息可能丟失)

用戶不顯式配置時(shí)，默認(rèn)值為1。如果是需要可靠性要求高的，建議設(shè)置為-1。設(shè)置為-1會(huì)影響吞吐的性能。

· retries

請(qǐng)求發(fā)生錯(cuò)誤時(shí)重試次數(shù)，建議將該值設(shè)置為大于0，失敗重試最大程度保證消息不丟失。

消費(fèi)的穩(wěn)定，看一下以下配置，主要避免重復(fù)消費(fèi)和頻繁的消費(fèi)組Rebalance：

· auto.offset.reset

表示當(dāng)Broker端沒有offset(如第一次消費(fèi)或 offset超過7天過期)時(shí)如何初始化 offset。earliest：表示自動(dòng)重置到 分區(qū) 的最小 offset

latest：默認(rèn)為 latest，表示自動(dòng)重置到分區(qū)的最大 offset

none：不自動(dòng)進(jìn)行 offset 重置，拋出 OffsetOutOfRangeException 異常

默認(rèn)值為latest。當(dāng)設(shè)置為earliest的時(shí)候，需要注意的是：當(dāng)offset失效后，就會(huì)從現(xiàn)存的最早的數(shù)據(jù)開始消費(fèi)的情況，可能會(huì)出現(xiàn)數(shù)據(jù)重復(fù)消費(fèi)的情況。

· session.timeout.ms

使用 Kafka 消費(fèi)分組機(jī)制時(shí)，消費(fèi)者超時(shí)的時(shí)間。當(dāng) Broker 在該時(shí)間內(nèi)沒有收到消費(fèi)者的心跳時(shí)，就會(huì)認(rèn)為該消費(fèi)者發(fā)生故障，Broker 發(fā)起重新 Rebalance 過程。目前該值的在 Broker 的配置必須在group.min.session.timeout.ms=6000和group.max.session.timeout.ms=300000 之間。

· heartbeat.interval.ms

使用 Kafka 消費(fèi)分組機(jī)制時(shí)，消費(fèi)者發(fā)送心跳的間隔。這個(gè)值必須小于 session.timeout.ms，一般小于它的三分之一。

· max.poll.interval.ms

使用 Kafka 消費(fèi)分組機(jī)制時(shí)，再次調(diào)用 poll 允許的最大間隔。如果在該時(shí)間內(nèi)沒有再次調(diào)用 poll，則認(rèn)為該消費(fèi)者已經(jīng)失敗，Broker 會(huì)重新發(fā)起 Rebalance 把分配給它的分區(qū) 分配給其他消費(fèi)者。

參數(shù)調(diào)優(yōu)只能最大程度保證服務(wù)的可用，并不能保證服務(wù)的百分百可用。客戶端需要具有捕獲生產(chǎn)，消費(fèi)等行為異常的行為。當(dāng)出現(xiàn)異常時(shí)，能夠告警，以便人工處理。這樣才能最大的保證業(yè)務(wù)的高可用。

CKafka的其他優(yōu)勢(shì)

CKafka除了作為消息管道幫助業(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)解耦、流量削峰外，還可以在其他場(chǎng)景有所作為。

日志分析系統(tǒng)

CKafka 結(jié)合大數(shù)據(jù)套件 EMR，可構(gòu)建完整的日志分析系統(tǒng)。首先通過部署在客戶端的 agent 進(jìn)行日志采集，并將數(shù)據(jù)聚合到消息隊(duì)列 CKafka，之后通過后端的大數(shù)據(jù)套件如 Spark 等進(jìn)行數(shù)據(jù)的多次計(jì)算消費(fèi)，并且對(duì)原始日志進(jìn)行清理，落盤存儲(chǔ)或進(jìn)行圖形化展示。

流數(shù)據(jù)處理平臺(tái)

CKafka 結(jié)合流計(jì)算 SCS , 可用于實(shí)時(shí)/離線數(shù)據(jù)處理及異常檢測(cè)，滿足不同場(chǎng)景需要：

1. 對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行分析和展示，并做異常檢測(cè)，快速定位系統(tǒng)問題。

2. 消費(fèi)歷史數(shù)據(jù)進(jìn)行落盤存儲(chǔ)和離線分析，對(duì)數(shù)據(jù)進(jìn)行二次加工，生成趨勢(shì)報(bào)表等。

結(jié)語

騰訊云CKafka作為高性能、高吞吐量的消息中間件，為千萬師生有序穩(wěn)定的線上課堂提供了性能支撐，有效的解決了數(shù)據(jù)的實(shí)時(shí)性和可靠性問題。特別是在業(yè)務(wù)故障時(shí)，可實(shí)現(xiàn)快速擴(kuò)縮容，并以其全面的容錯(cuò)機(jī)制和故障處理機(jī)制為用戶提供解決方案。

在2020年突如其來的疫情期間，CKafka將與騰訊課堂一起努力，為莘莘學(xué)子們百萬級(jí)的課堂互動(dòng)消息做好技術(shù)支撐，為構(gòu)建良好的線上課堂體驗(yàn)貢獻(xiàn)一份力量。

作者簡(jiǎn)介

許文強(qiáng), 騰訊云中間件消息隊(duì)列資深研發(fā)工程師。騰訊云Ckafka核心研發(fā)，擁有多年分布式系統(tǒng)研發(fā)經(jīng)驗(yàn)。主要負(fù)責(zé)騰訊云CKafka定制化開發(fā)及優(yōu)化工作。專注于Kafka在公有云多租戶和大規(guī)模集群場(chǎng)景下的性能分析和優(yōu)化。

總結(jié)

以上是生活随笔為你收集整理的可消费消息数量_战疫情！CKafka助力腾讯课堂百万消息实现稳定互动的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。