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

背景

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

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

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

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

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

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

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

騰訊課堂在線課程頁面

CKafka在騰訊課堂的實踐

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

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

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

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

消息的實時性

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

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

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

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

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

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

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

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

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

· 消費者的峰值帶寬

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

· 消費者的處理能力

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

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

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

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

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

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

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

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

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

提供如下信息供參考：

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

2. 單個分區(qū)只能被同消費者組的單個消費者進程消費。

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

4. 分區(qū)越多，當Leader節(jié)點失效后，其他分區(qū)重新進行Leader選舉的耗時就會越長。

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

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

消息的可靠性

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

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

關(guān)于副本

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

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

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

服務(wù)端的可靠性

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

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

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

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

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

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

· ack

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

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

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

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

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

· retries

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

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

· auto.offset.reset

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

latest：默認為 latest，表示自動重置到分區(qū)的最大 offset

none：不自動進行 offset 重置，拋出 OffsetOutOfRangeException 異常

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

· session.timeout.ms

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

· heartbeat.interval.ms

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

· max.poll.interval.ms

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

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

CKafka的其他優(yōu)勢

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

日志分析系統(tǒng)

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

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

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

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

2. 消費歷史數(shù)據(jù)進行落盤存儲和離線分析，對數(shù)據(jù)進行二次加工，生成趨勢報表等。

結(jié)語

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

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

作者簡介

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

總結(jié)

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

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