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作為消息隊列
如果你想要穩定的消息隊列
如果你想要你發送過的消息可以保留一定的時間,並不是無跡可尋的時候
如果你無法忍受數據的丟失
如果速度不需要那么的快
如果需要處理數據量巨大的時候
————————————————
版權聲明：本文為CSDN博主「Allen艾弗森」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_36285124/article/details/102617211