kafka多牛啊，老少通吃，風光無限，從業務服務到大數據，無所不能。

但，即使它這么牛x，在不少項目中，依然能看到很多的替代品，比如RabbitMQ、RocketMQ、Pulsar等。

等等，先不說這些同質的競爭品。在我見到的很多項目里，經常有一只亂入的消息隊列，那就是Redis。還別說，使用還挺廣泛的。

是他們傻？還是單純的水平不夠？

Redis很強

因為Kafka的對手是Redis！

redis很強，滿身的肌肉，幾乎是萬能的。如果你的內存足夠大，你甚至可以把所有的數據放到內存中。

除了常見的5種常見的數據結構，Redis還支持非常多的擴展數據結構，其中就有“借鑒”Kafka所實現的Stream類型。

Stream就是低配版的Kafka，有Kafka經驗的，玩起它來自然不在話下。相對于比較老舊的LPUSH/BRPOP、PUB/SUB模式，Stream在這個場景中完勝。

可以看到，Streamn的生產消費模式，幾乎和Kafka是一個模子出來的，竟然還有消費組的概念。但Stream并沒有Partition的概念，所以它是個低配版的Kafka。

我們來看看官網的說明。

Consumer groups were initially introduced by the popular messaging system Kafka (TM). Redis reimplements a similar idea in completely different terms, but the goal is the same: to allow a group of clients to cooperate in consuming a different portion of the same stream of messages.

Redis Can up

在很多軟件開發中，尤其是把軟件部署到甲方的機器上，引入一個新的組件，成本是巨大的。這方面，眾多外包和OD們應該比較清楚它的兇殘。

對于這類系統，甚至是發展勢頭還不錯的中小公司來說，對于消息的需求并沒有那么大的要求。與其引入一個新的Kafka組件，不如直接用項目中所存在的Redis組件來完成工作。

我們還是來回顧一下消息隊列的作用。

• 削峰

用于承接超出業務系統處理能力的請求，使業務平穩運行。這能夠大量節約成本，比如某些秒殺活動，并不是針對峰值設計容量。

• 緩沖

在服務層和緩慢的落地層作為緩沖層存在，作用與削峰類似，但主要用于服務內數據流轉。比如批量短信發送。

• 解耦

項目尹始，并不能確定具體需求。消息隊列可以作為一個接口層，解耦重要的業務流程。只需要遵守約定，針對數據編程即可獲取擴展能力。

• 冗余

消息數據能夠采用一對多的方式，供多個毫無關聯的業務使用。

• 健壯性

消息隊列可以堆積請求，所以消費端業務即使短時間死掉，也不會影響主要業務的正常進行。不好意思，除了內存容量小一點，上面說的這些需求，Redis的Stream全部能夠完成，包括對于緩存系統來說比較難得的持久化，它一樣支持。

那還猶豫個毛！怎么簡單怎么玩！

還有好處

Kafka為了增加吞吐量，可以說用盡了心思。比如，使用Filesystem Cache PageCache緩存來減少與磁盤的交互；使用順序寫來增加寫入的吞吐量；使用Zero-copy和MMAP來減少內存交換；使用批量，以流的方式進行交互，直頂網卡上限；使用拉模式進行消息的獲取消費，與消費端處理能力相符。

這么一優化下來，雖然功能很強大，但同時膨脹的還有代碼加上軟件的體積。

對于Redis來說，領域就在內存里玩，不需要這么多花架子就可以達到比Kafka更高的速度。就連partition這個特性，也可以使用不同的Key劃分來實現，性能自然是比Kafka高的。

再一個，就是使用簡單。

比如XADD指令、XLEN、XRANGE、XREAD等，指令少且好理解，遠比Kafka使用簡單。

這些優點一匯聚，就不能抵擋它成為MQ中的香饃饃。

簡單、夠用好維護，這么多優點，為什么不選Redis呢？給客戶上個又笨又重的Kafka、Pulsar，來給自己添麻煩，何必呢？

當然，以上的評價是對于外包、項目類公司來說的。如果你的公司產品是持續迭代的，持續優化的，又有量，一次性到位選擇成熟的額消息隊列才是正確的選擇。

所以，把Redis的Stream用在正確的項目，正確的地方的人，根本就不傻，他們大智若愚，堪負重任！