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作爲消息隊列
- 如果你想要穩定的消息隊列
- 如果你想要你發送過的消息可以保留一定的時間,並不是無跡可尋的時候
- 如果你無法忍受數據的丟失
- 如果速度不需要那麼的快
- 如果需要處理數據量巨大的時候