大卡夫卡消息VS小消息+ DB

在設計使用卡夫卡分離工作/ parallelise單位我發現，我有2所選擇的系統：大卡夫卡消息VS小消息+ DB

Data -> manipulate data -> store in DB -> send ID as message -> load data from DB using ID in message ->... 

Data -> manipulate data -> send data as message -> load data from message ->...

第二個選項擺脫所有的側面 - 影響數據保存和加載數據庫的代碼，如果我這樣做，那麼我的代碼更好，我的單位有時可以成爲一個純函數。我也減少了對數據庫的負載。缺點是這個消息可能很大，消息傳遞系統通常被設計爲快速消息。

我的問題是：

在什麼時候（多少字節）的消息開始顯得有點大了卡夫卡？
還有什麼其他的優點和缺點需要考慮？

來源

2015-01-08 shmish111

卡夫卡的大郵件沒有錯。一個潛在的問題是經紀人和消費者不得不解壓縮消息並因此使用他們的RAM。所以如果尺寸很大，它可能對RAM施加壓力（但我不確定什麼尺寸可以給你顯示結果）。

Benchmarking page from LinkedIn對有很好的解釋效果，消息大小爲。所以我會把它留在這裏。

我主要在小100字節的消息上顯示性能。較小的消息是消息傳遞系統的難題，因爲它們擴大了系統所執行的簿記管理的開銷。當我們改變記錄大小時，我們可以通過僅記錄吞吐量來記錄/秒和MB /秒。

enter image description here

所以，正如我們所期望的，這個圖顯示的記錄的原始統計數據，我們可以每秒發送減小作爲記錄變得更大。但是，如果我們看一下MB /秒，我們看到總字節吞吐量的真實用戶數據的比例隨着消息變得更大：

enter image description here

我們可以看到，與10點字節的信息，我們實際上是CPU的約束只是獲取鎖定並將消息排隊發送 - 我們無法實際將網絡最大化。然而，從100字節開始，我們實際上看到了網絡飽和（儘管隨着我們固定大小的簿記字節佔發送總字節的比例越來越小，MB/sec繼續增加）。

基於此，我不會過多擔心郵件的大小，只會繼續使用第二個簡單的解決方案。

來源

2015-01-22 10:51:16

非常有趣的閱讀。 – shmish111

@ shmish111不僅是消息大小的部分，也是整個文檔。很酷的事情是，它是從真正瞭解卡夫卡的人以及在一個大項目中使用卡巴卡的人開始的新事物。 –

也讓我想到，Kafka可以在某種CQRS環境下用作寫入速度非常快的數據存儲。例如，我們目前在cassandra中有文檔作爲「真實的來源」，它們都有TTL，如果信息單獨存儲以供查詢（例如在elasticsearch中），Kafka可以用更高的寫入能力取代它。我們大概可以減少我們使用相當多的盒子的數量...... – shmish111

kafka broker config中的message.max.bytes屬性定義了服務器可以接收的最大消息大小。默認值爲1000000該文檔說

服務器可以接收的消息的最大大小。此屬性與消費者使用的最大抓取大小同步，否則不守規矩的生產者將能夠發佈過大的消息以供消費者使用，這一點非常重要。

來源

2015-01-08 19:02:14 user2720864

對於消息大小是否對性能有很大影響，您是否有任何想法？ – shmish111

對於極端大的消息大小，生產者/消費者可能會耗盡內存。由於在Kafka消費者中沒有流式傳輸消息的概念，他們必須分配內存才能消費大量消息。您可以嘗試的一個選項是使用壓縮。但這真的取決於你的用例。 – user2720864

大卡夫卡消息VS小消息+ DB

回答

相關問題