kafka解決了什麼問題

1樓：

換乙個角度看為什麼需要kafka？

kafka與其他訊息佇列有什麼不一樣？

kafka與redis pub與sub功能的比較：

redis不支援 consumer group

2樓：hackerSunyifan

設計目標決定系統特性

Redis的設計目標是高效能快取系統，不是訊息佇列Kafka的設計目標是高效能，高可靠，可擴充套件的訊息佇列你當然可以拿Redis當訊息佇列，但必須對可能存在的訊息持久化，訊息處理確認機制，訊息插入和消費效率等等一系列問題做充足的預案

3樓：

簡單說幾點，在實現pub/sub這個功能上：

redis：快捷(尤其是你已經在其他地方使用到了redis)，成本低，但可靠性較差，訊息堆積能力差，沒有group功能，無法回放訊息等等

kafka：正規的訊息佇列技術，對於redis來說多了運維成本，普遍適用於海量訊息處理，可以克服上述redis的缺點，常用來處理日誌、監控等等

但如果涉及到支付、庫存等關鍵業務、事務的，上述技術一般都不適用不過redis的pub/sub用得很少，尤其是在大廠

4樓：車程式碼的

個人愚見，作為乙個訊息佇列的優質實現，Kafka解決了兩個方向的關鍵需求：一是大系統下各部分的解耦合(decoupling)，二是請求與響應不對稱情況下的削峰

5樓：

Redis 的 pub/sub 是經典的 fire-and-forget 訊息模型，這是一種一維的訊息模型。比如假設你的訊息型別是：

data

Message

你的接受函式是：

recv

::Message

處理流也只能是：

-- process :: Message -> Resultprocess

.recv

Kafka 是 log-based 訊息模型，這是一種二維的訊息模型，此時你的接受函式是：

recv

::Int

->Message

處理流是：

-- process :: Message -> Resultmap(

process

.recv)[

n..m]

綜上，在功能上（在不考慮效能的前提下），Redis pub/sub 可以做的 Kafka 都可以勝任，Kafka 可以做的 Redis pub/sub 則未必可以勝任（比如需要指定區間域的回溯等）。

6樓：張鵬飛

老闆有個好訊息要告訴大家，有兩個辦法:

1.到每個座位上挨個兒告訴每個人。什麼？張三去上廁所了？那張三就只能錯過好訊息了！

2.老闆把訊息寫到黑板報上，誰想知道就來看一下，什麼？張三請假了？

沒關係，我一周之後才擦掉，總會看見的！什麼張三請假兩周？那就算了，我反正只保留一周，不然其他好訊息沒地方寫了

redis用第一種辦法，kafka用第二種辦法，知道什麼區別了吧

7樓：yifhao

kakfa其實和傳統的分布式佇列系統不太一樣：速度非常快，線性擴充套件，流式處理，乙份訊息可多個消費者都處理，也可以只由乙個消費者處理。

這是由它的實現方式決定。

Kafka的實現思想是檔案直寫的commit log.

速度非常的快. 單機寫入速率可以達到幾十M~百M/S（基本接近磁碟直寫速率），如果訊息大小為百位元組級別的話，那麼也就是說單機寫入可以達到幾十W/S。

，通過新增partition檔案數量，就可以線性擴充套件乙個topic的處理能力。

Kafka的消費狀態是由消費者本身或外部儲存維護的（比如Zookeeper）。那麼不同的消費者就可以任意消費。同乙份訊息即可以用於實時分析，也可以用於存入離線分析平台。

Kafka可以解決什麼問題，更詳細的可以看我翻譯的Kafka權威指南第一章Meet Kafka。主要介紹系統如何一步步演進到Pub/Sub系統，Kafka的誕生背景，Kafka在LinkinIn解決了哪些問題。

獻醜了～

8樓：張琪

假設你意氣風發，要開發新一代的網際網路應用，以期在網際網路事業中一展巨集圖。借助雲計算，很容易開發出如下原型系統：

Web應用：部署在雲伺服器上，為個人電腦或者移動使用者提供的訪問體驗。

SQL資料庫：為Web應用提供資料持久化以及資料查詢。

好景不長。隨著使用者的迅速增長，所有的訪問都直接通過SQL資料庫使得它不堪重負，不得不加上快取服務以降低SQL資料庫的荷載；為了理解使用者行為，開始收集日誌並儲存到Hadoop上離線處理，同時把日誌放在全文檢索系統中以便快速定位問題；由於需要給投資方看業務狀況，也需要把資料彙總到資料倉儲中以便提供互動式報表。此時的系統的架構已經盤根錯節了，考慮將來還會加入實時模組以及外部資料互動，真是痛並快樂著……

這時候，應該跑慢一些，讓靈魂跟上來。

本質上，這是乙個資料整合問題。沒有任何乙個系統能夠解決所有的事情，所以業務資料根據不同用途存而放在不同的系統，比如歸檔、分析、搜尋、快取等。資料冗餘本身沒有任何問題，但是不同系統之間像義大利麵條一樣複雜的資料同步卻是挑戰。

這時候就輪到Kafka出場了。

Kafka可以讓合適的資料以合適的形式出現在合適的地方。Kafka的做法是提供訊息佇列，讓生產者單往佇列的末尾新增資料，讓多個消費者從佇列裡面依次讀取資料然後自行處理。之前連線的複雜度是O(N^2)，而現在降低到O(N)，擴充套件起來方便多了：

在Kafka的幫助下，你的網際網路應用終於能夠支撐飛速增長的業務，成為下乙個BAT指日可待。

以上故事說明了Kafka主要用途是資料整合，或者說是流資料整合，以Pub/Sub形式的訊息匯流排形式提供。但是，Kafka不僅僅是一套傳統的訊息匯流排，本質上Kafka是分布式的流資料平台，因為以下特性而著名：

提供Pub/Sub方式的海量訊息處理。

以高容錯的方式儲存海量資料流。

保證資料流的順序。

祝好運！

9樓：機械鍵盤俠

這個吧，主要看成本，訊息量小，自己寫資料庫都行，訊息量大了，如果用redis，成本很高啊。

redis比較火，不知道你聽說過redis他爹有另外乙個開源的訊息佇列，叫disque。

disque也是記憶體型的，並且集群內部智慧型程度挺高的，可惜也沒火起來。

kafka，rocketmq，都算同一系列的訊息中介軟體，在做好外圍管理系統的情況下，運維成本其實挺低的。

其實每個公司，基本都有一套自己的mq服務，目前開源的，除了上面的幾個，還有雅虎的pulsar，pulsar以bookkeeper作為儲存，其他廠商可能也有，我暫時沒聽說。

你要說有什麼具體的區別，就看看mq的幾個指標。

1、訊息堆積能力。兩億條1k大小訊息體的訊息發上來，積壓一周不消費，機器哭不哭。

2、吞吐量。來個峰值，每秒兩萬，連續兩小時，臨時擴容扛不扛得住。

3、安全性。一台機器，斷電，燒記憶體，壞硬碟，能不能保證訊息不丟失。

不管是redis，還是kafka，要是自己用，都得改造一遍。

當然了，如果只是存放日誌這種可以丟失的訊息，那就無所謂了。

10樓：huxihx

個人認為， Kafka與Redis PUB/SUB之間最大的區別在於Kafka是乙個完整的系統，而Redis PUB/SUB只是乙個套件(utility)——沒有冒犯Redis的意思，畢竟它的主要功能並不是PUB/SUB。

先說Redis吧，它首先是乙個記憶體資料庫，其提供的PUB/SUB功能把訊息儲存在記憶體中(基於channel)，因此如果你的訊息的永續性需求並不高且後端應用的消費能力超強的話，使用Redis PUB/SUB是比較合適的使用場景。比如官網說提供的乙個網路聊天室的例子：模擬IRC，因為channel就是IRC中的伺服器。

使用者發起連線，發布訊息到channel，接收其他使用者的訊息。這些對於永續性的要求並不高，使用Redis PUB/SUB來做足矣。

而Kafka是乙個完整的系統，它提供了乙個高吞吐量、分布式的提交日誌(由於提供了Kafka Connect和Kafka Streams，目前Kafka官網已經將自己修正為乙個分布式的流式處理平台，這裡也可以看出Kafka的野心：-)。除了p2p的訊息佇列，它當然提供PUB/SUB方式的訊息模型。

而且，Kafka預設提供了訊息的持久化，確保訊息的不丟失性(至少是大部分情況下)。另外，由於消費元資料是儲存在consumer端的，所以對於消費而言consumer被賦予極大的自由度。consumer可以順序地消費訊息，也可以重新消費之前處理過的訊息。

這些都是Redis PUB/SUB無法做到的。

最後總結一下，

Redis PUB/SUB使用場景：

1. 訊息永續性需求不高

2. 吞吐量要求不高

3. 可以忍受資料丟失

4. 資料量不大

Kafka使用場景：

上面以外的其他場景：）

1. 高可靠性

2. 高吞吐量

3. 永續性高

4. 多樣化的消費處理模型

kafka解決了什麼問題

CRM能解決什麼問題？

羅素的摹狀詞理論，解決了什麼問題？

Yammer 能幫助企業解決什麼問題？

其他用戶還看了：