kafka解決了什麼問題?

01-30

請高手指明一下kafka解決了什麼問題，什麼場景下使用？消息訂閱和發布嗎，好像redis也支持，功能是否有重疊？

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

Web應用：部署在雲伺服器上，為個人電腦或者移動用戶提供的訪問體驗。
SQL資料庫：為Web應用提供數據持久化以及數據查詢。

這套架構簡潔而高效，很快便能夠部署到百度雲等雲計算平台，以便快速推向市場。互聯網不就是講究小步快跑嘛！

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

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

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

這時候就輪到Kafka出場了。

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

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

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

提供Pub/Sub方式的海量消息處理。
以高容錯的方式存儲海量數據流。
保證數據流的順序。

更詳細的內容請見：雲上的卡夫卡 - 數據工會

個人認為， 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. 多樣化的消費處理模型

Apache kafka是消息中間件的一種，我發現很多人不知道消息中間件是什麼，在開始學習之前，我這邊就先簡單的解釋一下什麼是消息中間件，只是粗略的講解，目前kafka已經可以做更多的事情。

舉個例子，生產者消費者，生產者生產雞蛋，消費者消費雞蛋，生產者生產一個雞蛋，消費者就消費一個雞蛋，假設消費者消費雞蛋的時候噎住了（系統宕機了），生產者還在生產雞蛋，那新生產的雞蛋就丟失了。再比如生產者很強勁（大交易量的情況），生產者1秒鐘生產100個雞蛋，消費者1秒鐘只能吃50個雞蛋，那要不了一會，消費者就吃不消了（消息堵塞，最終導致系統超時），消費者拒絕再吃了，」雞蛋「又丟失了，這個時候我們放個籃子在它們中間，生產出來的雞蛋都放到籃子里，消費者去籃子里拿雞蛋，這樣雞蛋就不會丟失了，都在籃子里，而這個籃子就是」kafka「。

雞蛋其實就是「數據流」，系統之間的交互都是通過「數據流」來傳輸的（就是tcp、http什麼的），也稱為報文，也叫「消息」。

消息隊列滿了，其實就是籃子滿了，」雞蛋「放不下了，那趕緊多放幾個籃子，其實就是kafka的擴容。

各位現在知道kafka是幹什麼的了吧，它就是那個"籃子"

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

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

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

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

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

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

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

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

3、安全性。一台機器，斷電，燒內存，壞硬碟，能不能保證消息不丟失。

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

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

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

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

2.老闆把消息寫到黑板報上，誰想知道就來看一下，什麼？張三請假了？沒關係，我一周之後才擦掉，總會看見的！什麼張三請假兩周？那就算了，我反正只保留一周，不然其他好消息沒地方寫了

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

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

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

Kafka的實現思想是文件直寫的commit log.

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

kafka的一個topic中的record通過TopicPartitioner映射append到對應的稱為partition的文件末尾，通過添加partition文件數量，就可以線性擴展一個topic的處理能力。

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

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

http://m.blog.csdn.net/article/details?id=54172823

獻醜了～

Kafka是LinkedIn於2010年開源的消息系統，主要用於處理活躍的流式數據，活躍的流式數據在Web網站應用中很常見，這些數據包括網站的PV、用戶訪問了什麼內容、搜索了什麼內容等，這些數據通常以日誌的形式被記錄下來，然後每隔一段時間進行處理。

任何技術都是存在即合理，傳統的日誌分析系統提供了一種離線處理日誌消息的可擴展方案，但若要進行實時處理，通常會有較大延遲，而現有的消息（隊列）系統能夠很好地處理實時或者近似實時的應用，但未處理的數據不會寫到磁碟上，這對於Hadoop之類的離線應用而主，可能存在問題，Kafka正是為了解決以上問題而設計的，Kafka能夠很好地處理離線和在線應用。

Hadoop主要用於數據處理和存儲，用戶不了解分散式底層細節的情況下，開發分散式程序，充分利用集群，進行高速的運算和存儲，數據時代一定要知道，Hadoop是什麼，主要有哪幾部分組成和Hadoop的影響力？ - 大數據多智時代

如果你有簡單的數學思維素養就不難理解了。

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

data Message

你的接受函數是：

recv :: Message

處理流也只能是：

-- process :: Message -&> Result process . recv

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

recv :: Int -&> Message

處理流是：

-- process :: Message -&> Result map (process . recv) [n..m]

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

順序寫磁碟，優化了傳統消息隊列持久化到磁碟時的效率問題。

本身以partition方式設計，水平擴展及其容易。

拿Kafka和Redis比，是什麼鬼？Redis可以做緩存，Kafka可以嗎？好歹和RabbitMQ比一下才專業吧？