rabbit和kafka的優劣點(個人記憶)

2021-10-07 15:00:23 字數 792 閱讀 5061

核心點:資料結構的差異

順序性、訊息留存:

rabbit無法保證broker儲存資料的有序性,佇列是先入先出,消費者消費了,資料就出對了,這個資料就被刪除。  假如多個消費者消費同一佇列時,某一消費者消費失敗,資料回退到佇列了,但其他消費者卻已經消費成功了。這個時候順序就亂了,針對順序性要求高的業務就不支援了。

因為有乙個特性:消費者1消費某條資料時,不會阻礙其他消費者消費後面的資料

kafka:針對topic分割槽保證順序性,因為其資料不會丟失(除非超時),kafka 僅僅把它當做訊息日誌來看待,並不關心消費者的消費狀態。消費者可以不限次數的消費每條訊息,並且他們可以操作分割槽偏移來「及時」往返的處理這些訊息。

容錯性:重試

rabbitmq 可以配置重試次數。

在 rabbitmq 中我們需要記住最重要的事情是當乙個消費者正在處理或者重試某個訊息時(即使是在把它返回佇列之前),其他消費者都可以併發的處理這個訊息之後的其他訊息。

當某個消費者在重試處理某條訊息時,作為乙個整體的訊息處理邏輯不會被阻塞。

和 rabbitmq 相反,kafka 沒有提供這種開箱即用的機制。在 kafka 中,需要我們自己在應用層提供和實現訊息重試機制。

我們需要注意的是當乙個消費者正在同步地處理乙個特定的訊息時,那麼同在這個分割槽上的其他訊息是沒法被處理的。

由於消費者不能改變訊息的順序,所以我們不能夠拒絕和重試乙個特定的訊息以及提交乙個在這個訊息之後的訊息。你只要記住,分割槽僅僅是乙個追加模式的日誌。

即:如果消費者阻塞在重試乙個訊息上,那麼底部分割槽的訊息就不會被處理。

Redis訊息佇列和KafKa優劣對比

redis作為訊息佇列公升級為kafka記錄 專案當中運營人員傳送指定匹配使用者 最高使用者量幾十萬的級別 特定的訊息,所以這塊是確確實實需要使用專業級別的訊息佇列中介軟體的,但是可能由於當時開發的各種歷史原因導致使用了redis的佇列結構來作為訊息隊裡lpush,blpop等命令,專案開發進展到現...

empty 和size 的優劣

通常下面 if c.size 0 if c.empty 我們會覺得它們是是等價的。主要是他們之間的效率有一定差距 bool empty const list的empty操作 而size 則是通過區間遍歷來數一數。如果size 想在常數時間內實現,那麼每個操作都要維護size的值。splice 的特點...

nginx和apache的優劣分析

1 nginx相對於apache的優點 輕量級,同樣起web 服務,比apache 占用更少的記憶體及資源 抗併發,nginx 處理請求是非同步非阻塞的,而apache 則是阻塞型的,在高併發下nginx 能保持低資源低消耗高效能 高度模組化的設計,編寫模組相對簡單 社群活躍,各種高效能模組出品迅速...