摘要：話說阿里中間件團(tuán)隊(duì)和團(tuán)隊(duì)都做了一個(gè)的三者對比。所以大家一定要找準(zhǔn)自己的方向，不能因?yàn)榻裉彀⒗镎衅感枨筮@么寫就去學(xué)這些，明天看到一個(gè)技術(shù)很牛逼又去學(xué)那個(gè)。

在我們大量使用分布式數(shù)據(jù)庫、分布式計(jì)算集群的時(shí)候，是否會遇到這樣的一些問題：

我們想分析下用戶行為（pageviews），以便我們設(shè)計(jì)出更好的廣告位
我想對用戶的搜索關(guān)鍵詞進(jìn)行統(tǒng)計(jì)，分析出當(dāng)前的流行趨勢
有些數(shù)據(jù)，存儲數(shù)據(jù)庫浪費(fèi)，直接存儲硬盤效率又低

這些場景都有一個(gè)共同點(diǎn)：
數(shù)據(jù)是由上游模塊產(chǎn)生，上游模塊，使用上游模塊的數(shù)據(jù)計(jì)算、統(tǒng)計(jì)、分析，這個(gè)時(shí)候就可以使用消息系統(tǒng)，尤其是分布式消息系統(tǒng)！

知道了我們有必要在數(shù)據(jù)處理系統(tǒng)中使用一個(gè)消息系統(tǒng)，但是我們?yōu)槭裁匆欢ㄒxkafka呢？現(xiàn)在的消息系統(tǒng)可不只有kafka。

話說阿里中間件團(tuán)隊(duì)和LinkedIn團(tuán)隊(duì)都做了一個(gè)Kafka、RabbitMQ、RocketMQ的三者對比。這邊就不獻(xiàn)丑了，實(shí)際結(jié)果可以參考以下兩篇博文：

阿里測試：http://jm.taobao.org/2016/04/...

LinkedIn測試：https://blog.csdn.net/SJF0115...

Kafka是Linkedin于2010年12月份創(chuàng)建的開源消息系統(tǒng)，它主要用于處理活躍的流式數(shù)據(jù)。活躍的流式數(shù)據(jù)在web網(wǎng)站應(yīng)用中非常常見，這些活動(dòng)數(shù)據(jù)包括頁面訪問量（Page?View）、被查看內(nèi)容方面的信息以及搜索情況等內(nèi)容。?這些數(shù)據(jù)通常以日志的形式記錄下來，然后每隔一段時(shí)間進(jìn)行一次統(tǒng)計(jì)分析。

傳統(tǒng)的日志分析系統(tǒng)是一種離線處理日志信息的方式，但若要進(jìn)行實(shí)時(shí)處理，通常會有較大延遲。而現(xiàn)有的消息隊(duì)列系統(tǒng)能夠很好的處理實(shí)時(shí)或者近似實(shí)時(shí)的應(yīng)用，但未處理的數(shù)據(jù)通常不會寫到磁盤上，這對于Hadoop之類，間隔時(shí)間較長的離線應(yīng)用而言，在數(shù)據(jù)安全上會出現(xiàn)問題。Kafka正是為了解決以上問題而設(shè)計(jì)的，它能夠很好地進(jìn)行離線和在線應(yīng)用。

消息隊(duì)列（Message Queue，簡稱MQ），從字面意思上看，本質(zhì)是個(gè)隊(duì)列，F(xiàn)IFO先入先出，只不過隊(duì)列中存放的內(nèi)容是message而已。其主要用途：不同進(jìn)程Process/線程Thread之間通信。

高吞吐量：可以滿足每秒百萬級別消息的生產(chǎn)和消費(fèi)——生產(chǎn)消費(fèi)。

負(fù)載均衡：通過zookeeper對Producer,Broker,Consumer的動(dòng)態(tài)加入與離開進(jìn)行管理。

拉取系統(tǒng)：由于kafka?broker會持久化數(shù)據(jù)，broker沒有內(nèi)存壓力，因此，consumer非常適合采取pull的方式消費(fèi)數(shù)據(jù)

動(dòng)態(tài)擴(kuò)展：當(dāng)需要增加broker結(jié)點(diǎn)時(shí)，新增的broker會向zookeeper注冊，而producer及consumer會通過zookeeper感知這些變化，并及時(shí)作出調(diào)整。

消息刪除策略：數(shù)據(jù)文件將會根據(jù)broker中的配置要求,保留一定的時(shí)間之后刪除。kafka通過這種簡單的手段,來釋放磁盤空間。

啟動(dòng)Zookeeper及Broker.
Producer連接Broker后，將消息發(fā)布到Broker中指定Topic上(可以指定Patition)。
Broker集群接收到Producer發(fā)過來的消息后，將其持久化到硬盤，并將消息該保留指定時(shí)長（可配置），而不關(guān)注消息是否被消費(fèi)。
Consumer連接到Broker后，啟動(dòng)消息泵對Broker進(jìn)行偵聽，當(dāng)有消息到來時(shí)，會觸發(fā)消息泵循環(huán)獲取消息，獲取消息后Zookeeper將記錄該Consumer的消息Offset。

對于kafka而言，kafka服務(wù)就像是一個(gè)大的水池。不斷的生產(chǎn)、存儲、消費(fèi)著各種類別的消息。那么kafka由何組成呢？

Broker?：?Kafka消息服務(wù)器，消息中心。一個(gè)Broker可以容納多個(gè)Topic。

Producer?：消息生產(chǎn)者，就是向Kafka?broker發(fā)消息的客戶端。

Consumer?：消息消費(fèi)者，向Kafka?broker取消息的客戶端。

Zookeeper?：管理Producer，Broker，Consumer的動(dòng)態(tài)加入與離開。

Topic?：可以為各種消息劃分為多個(gè)不同的主題，Topic就是主題名稱。Producer可以針對某個(gè)主題進(jìn)行生產(chǎn)，Consumer可以針對某個(gè)主題進(jìn)行訂閱。

Consumer?Group：?Kafka采用廣播的方式進(jìn)行消息分發(fā)，而Consumer集群在消費(fèi)某Topic時(shí)，?Zookeeper會為該集群建立Offset消費(fèi)偏移量，最新Consumer加入并消費(fèi)該主題時(shí)，可以從最新的Offset點(diǎn)開始消費(fèi)。

Partition：Kafka采用對數(shù)據(jù)文件切片（Partition）的方式可以將一個(gè)Topic可以分布存儲到多個(gè)Broker上，一個(gè)Topic可以分為多個(gè)Partition。在多個(gè)Consumer并發(fā)訪問一個(gè)partition會有同步鎖控制。

有的時(shí)候，不光是燈紅酒綠的世界可以讓人沉迷，技術(shù)的世界也同樣如此。而且有的時(shí)候，技術(shù)的世界比前者更加可怕，它不但能讓你悄無聲息的陷入進(jìn)去，還能讓你產(chǎn)生一種你很上進(jìn)，你很努力的假象，以至于等到你恍然大悟那天，已經(jīng)悔之晚矣。

所以大家一定要找準(zhǔn)自己的方向，不能因?yàn)榻裉彀⒗镎衅感枨筮@么寫就去學(xué)這些，明天看到一個(gè)技術(shù)很牛逼又去學(xué)那個(gè)。因此我給大家推薦一個(gè)Java架構(gòu)群：895244712，里面有最清晰的互聯(lián)網(wǎng)架構(gòu)學(xué)習(xí)路線，更有具體的知識點(diǎn)講解，都是免費(fèi)的學(xué)習(xí)資源，推薦給大家。

目前該中間件只完成了初級階段功能，很多功能都不完善不深入，隨著應(yīng)用業(yè)務(wù)的拓展及Kafka未來版本功能支持。以Kafka消息中間件為中心的大數(shù)據(jù)處理平臺還有很多任務(wù)去實(shí)現(xiàn)。

一般在互聯(lián)網(wǎng)中所流動(dòng)的數(shù)據(jù)由以下幾種類型：

需要實(shí)時(shí)響應(yīng)的交易數(shù)據(jù)，用戶提交一個(gè)表單，輸入一段內(nèi)容，這種數(shù)據(jù)最后是存放在關(guān)系數(shù)據(jù)庫(Oracle,?MySQL)中的，有些需要事務(wù)支持。
活動(dòng)流數(shù)據(jù)，準(zhǔn)實(shí)時(shí)的，例如頁面訪問量、用戶行為、搜索情況等。我們可以針對這些數(shù)據(jù)廣播、排序、個(gè)性化推薦、運(yùn)營監(jiān)控等。這種數(shù)據(jù)一般是前端服務(wù)器先寫文件，然后通過批量的方式把文件倒到Hadoop(離線數(shù)據(jù)分析平臺)這種大數(shù)據(jù)分析器里面，進(jìn)行慢慢的分析。
各個(gè)層面程序產(chǎn)生的日志，例如http的日志、tomcat的日志、其他各種程序產(chǎn)生的日志。這種數(shù)據(jù)一個(gè)是用來監(jiān)控報(bào)警，還有就是用來做分析。