Redis 大數(shù)據(jù)技術(shù)相輔相成，沒有任何一種技術(shù)是沒有缺點，孤立發(fā)展的。今天咱們來分析下Kafka和Redis的對比，看分布式發(fā)布訂閱都有什么各自的優(yōu)勢與缺點。

我們注重客戶提出的每個要求，我們充分考慮每一個細節(jié)，我們積極的做好成都做網(wǎng)站、成都網(wǎng)站設(shè)計服務(wù)，我們努力開拓更好的視野，通過不懈的努力，成都創(chuàng)新互聯(lián)公司贏得了業(yè)內(nèi)的良好聲譽，這一切，也不斷的激勵著我們更好的服務(wù)客戶。 主要業(yè)務(wù)：網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)站設(shè)計,小程序設(shè)計,網(wǎng)站開發(fā),技術(shù)開發(fā)實力，DIV+CSS，PHP及ASP，ASP.Net，SQL數(shù)據(jù)庫的技術(shù)開發(fā)工程師。

 前言

大數(shù)據(jù)技術(shù)相輔相成，沒有任何一種技術(shù)是沒有缺點，孤立發(fā)展的。今天咱們來分析下Kafka和Redis的對比，看分布式發(fā)布訂閱都有什么各自的優(yōu)勢與缺點。

Redis是什么

Redis 是開源免費的，遵守BSD協(xié)議，是一個高性能的key-value非關(guān)系型數(shù)據(jù)庫?？赡苡信笥褧枺琑edis作為存儲數(shù)據(jù)庫，怎么和分布式發(fā)布訂閱消息系統(tǒng)Kafka對比？兩者本身不是同一個層次的東西啊。

但是Redis中有一個queue的數(shù)據(jù)類型，用來做發(fā)布/訂閱系統(tǒng)，這個就可以和kafka進行比較了。

kafka是什么

Kafka 是一個高吞吐、分布式、基于發(fā)布訂閱的消息系統(tǒng)，利用Kafka技術(shù)可在廉價PC Server上搭建起大規(guī)模消息系統(tǒng)。Kafka具有消息持久化、高吞吐、分布式、多客戶端支持、實時等特性

現(xiàn)在干貨來了，kafka和Redis的區(qū)別聯(lián)系

存儲介質(zhì)不同

redis queue數(shù)據(jù)是存儲在內(nèi)存，雖然有AOF和RDB的持久化方式，但是還是以內(nèi)存為主。

kafka是存儲在硬盤上

性能不同

因為存儲介質(zhì)不同，理論上redis queue的性能要優(yōu)于kafka，但是在實際使用過程，這塊體驗并不是很明顯，通常只有一些高并發(fā)場景下需要用redis queue，比如發(fā)紅包，可以先將紅包預先拆解然后push到redis queue，在搶的一瞬間可以很好的支撐并發(fā)。

成本不同

這邊要劃重點，劃重點，劃重點。

kafka存儲在硬盤上，成本會比內(nèi)存小很多，具體差1，2個數(shù)量級是有，在數(shù)據(jù)量非常大的情況下，使用kafka能夠節(jié)省蠻多服務(wù)器成本。最常見的有應用產(chǎn)生的日志，這些日志產(chǎn)生的量級一般都很大，如果有需要進行處理，可以使用kafka隊列。

這只是簡單的介紹原始差距，咱們再來看核心對比——作為消息隊列的優(yōu)劣對比

Redis作為消息隊列

redis發(fā)布（pub）、訂閱（sub）模式

redis中的發(fā)布訂閱由三部分組成。發(fā)布者（生產(chǎn)者）、通道（類似于topic）、訂閱者（消費者），具體結(jié)構(gòu)如下圖：

Redis的pub-sub模式非常像西式快餐一樣,快餐快消,全都是因為Redis是使用內(nèi)存來做存取,所有你生產(chǎn)的消息立馬會被消費者一次性全部處理掉,并且沒有留下任何痕跡, 同時因為內(nèi)存總是寶貴的,所以內(nèi)存上會有限制,當生產(chǎn)者以及消費者上來的時候也會對redis的效率,還有Redis在處理發(fā)布和消費big size(10K+的文件)的數(shù)據(jù)的時候會表現(xiàn)出無法忍受的緩慢

　　如果有以下場景可以考慮使用Redis作為消息隊列

• 　如果你的需求是快產(chǎn)快消的即時消費場景,并且生產(chǎn)的消息立即被消費者消費掉
• 　如果速度是你十分看重的,比如慢了一秒好幾千萬這種
• 　如果允許出現(xiàn)消息丟失的場景
• 　如果你不需要系統(tǒng)保存你發(fā)送過的消息,做到來無影去無蹤
• 　如果需要處理的數(shù)據(jù)量并不是那么巨大

KafKa作為消息隊列

　　KafKa的設(shè)計精妙,支持分布式,高可用的部署,并且對一個大的隊列采用分成多個Partition(分區(qū)),來提高消息入隊的吞吐量,分而治之的思想. 并且消費的時候支持group的概念,能夠支持多個客戶端消費同個隊列,并且一個group中可以增加consumer的數(shù)量來擴展消費的處理量.

　　KafKa不受生產(chǎn)者數(shù)量的影響,因為吞吐量足夠支撐,即使在廉價的單機服務(wù)器上也可以有10萬每秒的消息傳輸量,并且消費者是想什么時候消費都可以,消息它就在那里,十分靈活,不用擔心來無影去無蹤的恐慌.能把消息持久化,并以一定的策略(例如一定時間內(nèi)刪除,或者到達多大容量的時候清空)

　　當有一下場景的時候你可以考慮使用KafKa作為消息隊列

• 　如果你想要穩(wěn)定的消息隊列
• 　如果你想要你發(fā)送過的消息可以保留一定的時間,并不是無跡可尋的時候
• 　如果你無法忍受數(shù)據(jù)的丟失
• 　如果速度不需要那么的快
• 　如果需要處理數(shù)據(jù)量巨大的時候

后結(jié)

[[325998]]

Redis 是以 key 的 hash 方式來分散對列存儲數(shù)據(jù)的，且 Redis 作為集群使用時，對應的應用對應一個 Redis，在某種程度上會造成數(shù)據(jù)的傾斜性，從而導致數(shù)據(jù)的丟失。

而從之前部署 Kafka 集群來看，kafka 的一個 topic（主題），可以有多個 partition（副本），而且是均勻的分布在 Kafka 集群上，這就不會出現(xiàn) redis 那樣的數(shù)據(jù)傾斜性。Kafka 同時也具備 Redis 的冗余機制，像 Redis 集群如果有一臺機器宕掉是很有可能造成數(shù)據(jù)丟失，而 Kafka 因為是均勻的分布在集群主機上，即使宕掉一臺機器，是不會影響使用。同時 Kafka 作為一個訂閱消息系統(tǒng)，還具備每秒百萬級別的高吞吐量，持久性的、分布式的特點等。

文章標題：你知道Kafka和Redis的各自優(yōu)缺點嗎？一文帶你優(yōu)化選擇
鏈接分享：http://uogjgqi.cn/article/cohghgo.html