1，Redis作為消息隊列
Redis的pub-sub模式很像西式快餐。都是因為Redis使用內存進行訪問，妳產生的所有消息都會被消費者壹次性處理，不留任何痕跡。同時，因為內存永遠是寶貴的，內存會有限制，生產者和消費者上來也會影響Redis的效率，Redis處理的是發布和消費大尺寸(10K+文件)。
如果有以下情況，可以考慮使用Redis作為消息隊列:
a、如果妳的需求是快生產快消費的即時消費場景，生產的消息馬上被消費者消費。
b、如果速度是妳非常看重的東西，比如幾千萬秒慢。
C.如果允許消息丟失的場景。
d、如果不需要系統保存妳發的消息，讓它們來去無蹤。
e，要處理的數據量沒有那麽龐大。
2.作為信息隊列的卡夫卡
KafKa設計精巧，支持分布式、高可用部署，采用將壹個大隊列分成多個分區的思想，提高消息隊列的吞吐量，分而治之。它還支持消費時的分組概念，支持多個客戶端消費同壹個隊列，並且可以增加壹個組中的消費者數量來擴展消費的處理能力。
由於卡夫卡不成熟制作人數量的影響，即使在廉價的單機服務器上，每秒鐘也能有6.5438億+條消息，消費者可以隨時消費。消息就在那裏，所以很靈活，不用擔心來去無蹤的恐慌。消息可以用壹定的策略持久化和清空(比如壹定時間內刪除或者達到大容量)。
有場景的時候，可以考慮用卡夫卡做消息隊列:
如果妳想要壹個穩定的消息隊列
b、如果妳想把妳發的信息保留壹段時間，那就不是沒有痕跡的時候。
c、如果妳不能忍受數據丟失
d、如果速度不需要那麽快
e、如果需要處理海量數據。