redis作為訊息佇列公升級為kafka記錄
專案當中運營人員傳送指定匹配使用者(最高使用者量幾十萬的級別)特定的訊息,所以這塊是確確實實需要使用專業級別的訊息佇列中介軟體的,但是可能由於當時開發的各種歷史原因導致使用了redis的佇列結構來作為訊息隊裡lpush,blpop等命令,專案開發進展到現在,使用者量不斷增大,包括不同的訊息繼承進來,包括舉報反饋,小紙條(使用者間訊息傳送),活動獎勵通知,等等一些不同的訊息進來以後,redis可能會變得不那麼可靠.
redis作為訊息佇列
redis的pub-sub模式非常像西式快餐一樣,快產快消,全都是因為redis是使用記憶體來做訪問,所有你生產的訊息立馬會被消費者一次性全部處理掉,並且沒有留下任何痕跡, 同時因為記憶體總是寶貴的,所以記憶體上會有限制,當生產者以及消費者上來的時候也會對redis的效率,還有redis在處理發布和消費big size(10k+的檔案)的資料的時候會表現出無法忍受的緩慢
如果有以下場景可以考慮使用redis作為訊息佇列
如果你的需求是快產快消的即時消費場景,並且生產的訊息立即被消費者消費掉
如果速度是你十分看重的,比如慢了一秒好幾千萬這種
如果允許出現訊息丟失的場景
如果你不需要系統儲存你傳送過的訊息,做到來無影去無蹤
需要處理的資料量並不是那麼巨大
kafka作為訊息佇列
kafka的設計精妙,支援分布式,高可用的部署,並且對乙個大的佇列採用分成多個partition(分割槽),來提高訊息入隊的吞吐量,分而治之的思想. 並且消費的時候支援group的概念,能夠支援多個客戶端消費同個佇列,並且乙個group中可以增加consumer的數量來擴充套件消費的處理量.
kafka不熟生產者數量的影響,因為吞吐量足夠支撐,即使在廉價的單機伺服器上也可以有10萬每秒的訊息傳輸量,並且消費者是想什麼時候消費都可以,訊息它就在那裡,十分靈活,不用擔心來無影去無蹤的恐慌.能把訊息持久化,並以一定的策略(例如一定時間內刪除,或者到達多大容量的時候清空)
當有一下場景的時候你可以考慮使用kafka作為訊息佇列
訊息佇列 訊息佇列 kafka
kafka是乙個分布式的基於發布 訂閱模式的訊息佇列，主要用於大資料實時處理領域。要理解kafka首先要有分布式的概念，要有訊息佇列的概念。分布式系統最大的優勢就是解耦和削峰，這種情況下，a系統生成了乙個訊息，b系統非同步獲取，那麼就需要乙個存放訊息的訊息佇列 mq 相比較傳統的訊息佇列，訊息被消費...
訊息佇列 Kafka和rabbitMQ
0.建立topic bin kafka topics.sh create zookeeper localhost 2181 replication factor1 partitions1 topic test 1.檢視kafka topic列表 bin kafka topic.sh zoopkeep...
訊息佇列 RabbitMQ和Kafka
2種模式 點對點 consumer主動對queue監控，檢查是否收到訊息 優點 解耦 通過中介軟體通訊 冗餘 可做快取 擴充套件性順序保證 非同步通訊 consumer即使down掉，訊息還是儲存在queue，等consumer恢復會自動處理訊息 關於broker裡的exchange不可以直接將訊息...