請(qǐng)高手指明一下kafka解決了什么問題，什么場(chǎng)景下使用？消息訂閱和發(fā)布嗎，好像redis也支持，功能是否有重疊？

作者：張琪
鏈接：https://www.zhihu.com/question/53331259/answer/139862117
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
?

假設(shè)你意氣風(fēng)發(fā)，要開發(fā)新一代的互聯(lián)網(wǎng)應(yīng)用，以期在互聯(lián)網(wǎng)事業(yè)中一展宏圖。借助云計(jì)算，很容易開發(fā)出如下原型系統(tǒng)：

Web應(yīng)用：部署在云服務(wù)器上，為個(gè)人電腦或者移動(dòng)用戶提供的訪問體驗(yàn)。

SQL數(shù)據(jù)庫：為Web應(yīng)用提供數(shù)據(jù)持久化以及數(shù)據(jù)查詢。

這套架構(gòu)簡(jiǎn)潔而高效，很快便能夠部署到百度云等云計(jì)算平臺(tái)，以便快速推向市場(chǎng)。互聯(lián)網(wǎng)不就是講究小步快跑嘛！

好景不長。隨著用戶的迅速增長，所有的訪問都直接通過SQL數(shù)據(jù)庫使得它不堪重負(fù)，不得不加上緩存服務(wù)以降低SQL數(shù)據(jù)庫的荷載；為了理解用戶行為，開始收集日志并保存到Hadoop上離線處理，同時(shí)把日志放在全文檢索系統(tǒng)中以便快速定位問題；由于需要給投資方看業(yè)務(wù)狀況，也需要把數(shù)據(jù)匯總到數(shù)據(jù)倉庫中以便提供交互式報(bào)表。此時(shí)的系統(tǒng)的架構(gòu)已經(jīng)盤根錯(cuò)節(jié)了，考慮將來還會(huì)加入實(shí)時(shí)模塊以及外部數(shù)據(jù)交互，真是痛并快樂著……

這時(shí)候，應(yīng)該跑慢一些，讓靈魂跟上來。

本質(zhì)上，這是一個(gè)數(shù)據(jù)集成問題。沒有任何一個(gè)系統(tǒng)能夠解決所有的事情，所以業(yè)務(wù)數(shù)據(jù)根據(jù)不同用途存而放在不同的系統(tǒng)，比如歸檔、分析、搜索、緩存等。數(shù)據(jù)冗余本身沒有任何問題，但是不同系統(tǒng)之間像意大利面條一樣復(fù)雜的數(shù)據(jù)同步卻是挑戰(zhàn)。

這時(shí)候就輪到Kafka出場(chǎng)了。

Kafka可以讓合適的數(shù)據(jù)以合適的形式出現(xiàn)在合適的地方。Kafka的做法是提供消息隊(duì)列，讓生產(chǎn)者單往隊(duì)列的末尾添加數(shù)據(jù)，讓多個(gè)消費(fèi)者從隊(duì)列里面依次讀取數(shù)據(jù)然后自行處理。之前連接的復(fù)雜度是O(N^2)，而現(xiàn)在降低到O(N)，擴(kuò)展起來方便多了：

在Kafka的幫助下，你的互聯(lián)網(wǎng)應(yīng)用終于能夠支撐飛速增長的業(yè)務(wù)，成為下一個(gè)BAT指日可待。

以上故事說明了Kafka主要用途是數(shù)據(jù)集成，或者說是流數(shù)據(jù)集成，以Pub/Sub形式的消息總線形式提供。但是，Kafka不僅僅是一套傳統(tǒng)的消息總線，本質(zhì)上Kafka是分布式的流數(shù)據(jù)平臺(tái)，因?yàn)橐韵绿匦远?#xff1a;

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

以高容錯(cuò)的方式存儲(chǔ)海量數(shù)據(jù)流。

保證數(shù)據(jù)流的順序。

作者：huxihx
鏈接：https://www.zhihu.com/question/53331259/answer/134529226
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
?

個(gè)人認(rèn)為， Kafka與Redis PUB/SUB之間最大的區(qū)別在于Kafka是一個(gè)完整的系統(tǒng)，而Redis PUB/SUB只是一個(gè)套件(utility)——沒有冒犯Redis的意思，畢竟它的主要功能并不是PUB/SUB。

先說Redis吧，它首先是一個(gè)內(nèi)存數(shù)據(jù)庫，其提供的PUB/SUB功能把消息保存在內(nèi)存中(基于channel)，因此如果你的消息的持久性需求并不高且后端應(yīng)用的消費(fèi)能力超強(qiáng)的話，使用Redis PUB/SUB是比較合適的使用場(chǎng)景。比如官網(wǎng)說提供的一個(gè)網(wǎng)絡(luò)聊天室的例子：模擬IRC，因?yàn)閏hannel就是IRC中的服務(wù)器。用戶發(fā)起連接，發(fā)布消息到channel，接收其他用戶的消息。這些對(duì)于持久性的要求并不高，使用Redis PUB/SUB來做足矣。

而Kafka是一個(gè)完整的系統(tǒng)，它提供了一個(gè)高吞吐量、分布式的提交日志(由于提供了Kafka Connect和Kafka Streams，目前Kafka官網(wǎng)已經(jīng)將自己修正為一個(gè)分布式的流式處理平臺(tái)，這里也可以看出Kafka的野心：-)。除了p2p的消息隊(duì)列，它當(dāng)然提供PUB/SUB方式的消息模型。而且，Kafka默認(rèn)提供了消息的持久化，確保消息的不丟失性(至少是大部分情況下)。另外，由于消費(fèi)元數(shù)據(jù)是保存在consumer端的，所以對(duì)于消費(fèi)而言consumer被賦予極大的自由度。consumer可以順序地消費(fèi)消息，也可以重新消費(fèi)之前處理過的消息。這些都是Redis PUB/SUB無法做到的。

最后總結(jié)一下，
Redis PUB/SUB使用場(chǎng)景：
1. 消息持久性需求不高
2. 吞吐量要求不高
3. 可以忍受數(shù)據(jù)丟失
4. 數(shù)據(jù)量不大

Kafka使用場(chǎng)景：
上面以外的其他場(chǎng)景：）
1. 高可靠性
2. 高吞吐量
3. 持久性高
4. 多樣化的消費(fèi)處理模型

Apache kafka是消息中間件的一種，我發(fā)現(xiàn)很多人不知道消息中間件是什么，在開始學(xué)習(xí)之前，我這邊就先簡(jiǎn)單的解釋一下什么是消息中間件，只是粗略的講解，目前kafka已經(jīng)可以做更多的事情。

舉個(gè)例子，生產(chǎn)者消費(fèi)者，生產(chǎn)者生產(chǎn)雞蛋，消費(fèi)者消費(fèi)雞蛋，生產(chǎn)者生產(chǎn)一個(gè)雞蛋，消費(fèi)者就消費(fèi)一個(gè)雞蛋，假設(shè)消費(fèi)者消費(fèi)雞蛋的時(shí)候噎住了（系統(tǒng)宕機(jī)了），生產(chǎn)者還在生產(chǎn)雞蛋，那新生產(chǎn)的雞蛋就丟失了。再比如生產(chǎn)者很強(qiáng)勁（大交易量的情況），生產(chǎn)者1秒鐘生產(chǎn)100個(gè)雞蛋，消費(fèi)者1秒鐘只能吃50個(gè)雞蛋，那要不了一會(huì)，消費(fèi)者就吃不消了（消息堵塞，最終導(dǎo)致系統(tǒng)超時(shí)），消費(fèi)者拒絕再吃了，”雞蛋“又丟失了，這個(gè)時(shí)候我們放個(gè)籃子在它們中間，生產(chǎn)出來的雞蛋都放到籃子里，消費(fèi)者去籃子里拿雞蛋，這樣雞蛋就不會(huì)丟失了，都在籃子里，而這個(gè)籃子就是”kafka“。
雞蛋其實(shí)就是“數(shù)據(jù)流”，系統(tǒng)之間的交互都是通過“數(shù)據(jù)流”來傳輸?shù)?#xff08;就是tcp、http什么的），也稱為報(bào)文，也叫“消息”。
消息隊(duì)列滿了，其實(shí)就是籃子滿了，”雞蛋“ 放不下了，那趕緊多放幾個(gè)籃子，其實(shí)就是kafka的擴(kuò)容。
各位現(xiàn)在知道kafka是干什么的了吧，它就是那個(gè)"籃子"

作者：極限求知者
鏈接：https://www.zhihu.com/question/53331259/answer/241614605
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

來源:https://www.zhihu.com/question/53331259

總結(jié)

以上是生活随笔為你收集整理的kafka解决了什么问题?的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。