kafka多牛啊，老少通吃，風(fēng)光無限，從業(yè)務(wù)服務(wù)到大數(shù)據(jù)，無所不能。

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

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

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

Redis很強(qiáng)

因?yàn)镵afka的對手是Redis！

redis很強(qiáng)，滿身的肌肉，幾乎是萬能的。如果你的內(nèi)存足夠大，你甚至可以把所有的數(shù)據(jù)放到內(nèi)存中。

除了常見的5種常見的數(shù)據(jù)結(jié)構(gòu)，Redis還支持非常多的擴(kuò)展數(shù)據(jù)結(jié)構(gòu)，其中就有“借鑒”Kafka所實(shí)現(xiàn)的Stream類型。

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

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

我們來看看官網(wǎng)的說明。

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

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

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

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

• 削峰

用于承接超出業(yè)務(wù)系統(tǒng)處理能力的請求，使業(yè)務(wù)平穩(wěn)運(yùn)行。這能夠大量節(jié)約成本，比如某些秒殺活動(dòng)，并不是針對峰值設(shè)計(jì)容量。

• 緩沖

在服務(wù)層和緩慢的落地層作為緩沖層存在，作用與削峰類似，但主要用于服務(wù)內(nèi)數(shù)據(jù)流轉(zhuǎn)。比如批量短信發(fā)送。

• 解耦

項(xiàng)目尹始，并不能確定具體需求。消息隊(duì)列可以作為一個(gè)接口層，解耦重要的業(yè)務(wù)流程。只需要遵守約定，針對數(shù)據(jù)編程即可獲取擴(kuò)展能力。

• 冗余

消息數(shù)據(jù)能夠采用一對多的方式，供多個(gè)毫無關(guān)聯(lián)的業(yè)務(wù)使用。

• 健壯性

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

那還猶豫個(gè)毛！怎么簡單怎么玩！

還有好處

Kafka為了增加吞吐量，可以說用盡了心思。比如，使用Filesystem Cache PageCache緩存來減少與磁盤的交互；使用順序?qū)憗碓黾訉懭氲耐掏铝?；使用Zero-copy和MMAP來減少內(nèi)存交換；使用批量，以流的方式進(jìn)行交互，直頂網(wǎng)卡上限；使用拉模式進(jìn)行消息的獲取消費(fèi)，與消費(fèi)端處理能力相符。

這么一優(yōu)化下來，雖然功能很強(qiáng)大，但同時(shí)膨脹的還有代碼加上軟件的體積。

對于Redis來說，領(lǐng)域就在內(nèi)存里玩，不需要這么多花架子就可以達(dá)到比Kafka更高的速度。就連partition這個(gè)特性，也可以使用不同的Key劃分來實(shí)現(xiàn)，性能自然是比Kafka高的。

再一個(gè)，就是使用簡單。

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

這些優(yōu)點(diǎn)一匯聚，就不能抵擋它成為MQ中的香饃饃。

簡單、夠用好維護(hù)，這么多優(yōu)點(diǎn)，為什么不選Redis呢？給客戶上個(gè)又笨又重的Kafka、Pulsar，來給自己添麻煩，何必呢？

當(dāng)然，以上的評價(jià)是對于外包、項(xiàng)目類公司來說的。如果你的公司產(chǎn)品是持續(xù)迭代的，持續(xù)優(yōu)化的，又有量，一次性到位選擇成熟的額消息隊(duì)列才是正確的選擇。

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