Kafka訊息的可靠性測試--針對直播業務的方案選擇

標籤：

轉自：http://blog.csdn.net/bailove/article/details/44240303

 

業務情境

 

來瘋直播互動平台，每天有數百萬人上下線，有數十萬人同時參與互動直播聊天。使用者的登陸、退出及使用者間的各種互動行為如聊天、送禮、關注、投票、搶沙發等等事件都會產生大量的訊息。這些訊息具有瞬間爆發性，比如熱門直播間剛開播，直播表演的高潮等等。而使用者的禮物、星星、喇叭、沙發等這類訊息是不允許丟失，必須100%送達。這就需要有一個高效能，高可靠，穩定可拓展的Message Service平台的支撐。它要求在網路壓力大及伺服器宕機等災害的情況下，保證訊息至少被發送到伺服器一次。我們需要對大資料平台已提供的Message Servicekafka進行測試。

 

測試環境

 

cpu：24 Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz

記憶體：32G

磁碟數量：1 （普通sata盤）

kafka版本：0.8.2

叢集規模：4節點

Topic副本數：3

Topic分區數(partition)：4

 

災難類比

 

1. 訊息發送過程中宕掉其中一個節點，或同時宕掉兩個節點（最多同時宕2台，因為副本數為3）

2. 頻繁宕機重啟其中某個節點

3. 交替宕機重啟某一個或兩個broker但是保證不能同時有3個節點宕機

（PS：同時出現三個節點宕機的情況，在近1年多運營中我們還沒有遇到過，最多出現兩個點宕機。)

 

測試結果

 

結論

 

同步_ack模式能夠保證訊息至少被發送一次到伺服器。在三備份情況下，kafka叢集不同時宕機兩台以上時，能夠正常給生產端和消費端提供服務。但是採用這種模式可能由於網路或服務問題導致重複發送資料，所以消費端的消費操作需要是等冪的。

 

同步_ack非batch

 

同步_ack 在不做batch的情況下單進程的發送效率比較低發送速率大概 500kb/s，增加進程數量可以提高總的發送效率。

 

採用這種模式，資料丟失或表現為丟失情況：

①:kafka伺服器同時宕機三台以上時（副本數為3),由於沒有leader服務導致producer產生的資料沒有寫入kafka，資料丟失。

 

②:消費端程式宕機,可能造成業務方面的統計錯誤，表現為資料丟失。此時資料沒有真正丟失而是消費端消費掉的部分訊息沒有執行完商務邏輯表現的出來的資料丟失。消費端出現這種情況，需要有資料復原，重新消費，補資料的機制。

 

同步_ack_batch

 

同步_ack_ batch(200條)的情況下基本達到非同步_noack不做batch模式的發送速率。單用戶端7m/s(如果增大batch量這個速率還會增加）,多用戶端基本呈線性增加，瓶頸受限於網路頻寬。

 

採用這種模式，資料丟失或表現為丟失情況：

①:同上

②:同上

③:因是batch發送，producer會緩衝了一部分資料，如果producer宕機會造成batch在記憶體中且還沒發送出去的訊息丟失。對於這種情況producer端需要做訊息持久化,定時做offset的checkpoint,將已經持久化的訊息發送到kafka，如果producer意外宕機，那麼從checkpoint開始恢複資料重新發送。

 

參考方案

 

針對來瘋的業務情境，我們大概可以將訊息分為以下三種：

 

1.資料量大，且允許少量資料丟失。例如使用者進入頻道、聊天、上下線等採用非同步_noack模式

 

2.資料量不大，資料不允許丟失。例如使用者金喇叭、搶沙發、守護等採用同步_ack模式

 

3.資料量大，資料不允許丟失。例如使用者使用星星、送禮物、投票等Producer採用同步_ack_batch模式

 

針對不同類訊息的應用情境定製不同的發送策略，來保證訊息能夠可靠高效的發送到kafka服務端。

 

當然要保證業務可靠，除了kafka服務端的訊息可靠性及效能保障外，用戶端（生產端和消費端）還要做到資料持久化，資料校正及恢複，等冪操作及事務等。

 

此外營運也是必不可少的一環，監控用戶端及服務端的各項狀態，對異常情況快速警示,及時處理以保證kafka叢集穩定。後續我們將繼續推出kafka、storm運營相關的文章，盡情期待！

 

------作者簡曆-----------

楊萬民,畢業於北京郵電大學，目前就職於優酷馬鈴薯大資料基礎平台，負責集團即時計算平台的最佳化與運營。個人專註於storm、kafka底層技術研究。

Kafka訊息的可靠性測試--針對直播業務的方案選擇