分散式訊息系統Kafka初步

終於可以寫kafka的文章了，Mina的相關文章我已經做了索引，在我的部落格中置頂了，大家可以方便的找到。從這一篇開始分散式訊息系統的入門。

在我們大量使用分散式資料庫、分散式計算叢集的時候，是否會遇到這樣的一些問題：

l  我想分析一下使用者行為（pageviews），以便我能設計出更好的廣告位

l  我想對使用者的搜尋關鍵詞進行統計，分析出當前的流行趨勢。這個很有意思，在經濟學上有個長裙理論，就是說，如果長裙的銷量高了，說明經濟不景氣了，因為姑娘們沒錢買各種絲襪了。

l  有些資料，我覺得存資料庫浪費，直接存硬碟又怕到時候操作效率低。

這個時候，我們就可以用到分散式訊息系統了。雖然上面的描述更偏向於一個日誌系統，但確實kafka在實際應用中被大量的用於日誌系統。

首先我們要明白什麼是訊息系統，在kafka官網上對kafka的定義叫：A distributed publish-subscribe messaging system。publish-subscribe是釋出和訂閱的意思，所以更準確的說kafka是一個訊息訂閱和釋出的系統。publish-subscribe這個概念很重要，因為kafka的設計理念就可以從這裡說起。

我們將訊息的釋出（publish）暫時稱作producer，將訊息的訂閱（subscribe）表述為consumer，將中間的儲存陣列稱作broker，這樣我們就可以大致描繪出這樣一個場面：

生產者（藍色，藍領麼，總是辛苦點兒）將資料生產出來，丟給broker進行儲存，消費者需要消費資料了，就從broker中去拿出資料來，然後完成一系列對資料的處理。

乍一看這也太簡單了，不是說了它是分散式麼，難道把producer、broker和consumer放在三臺不同的機器上就算是分散式了麼。我們看kafka官方給出的圖：

多個broker協同合作，producer和consumer部署在各個業務邏輯中被頻繁的呼叫，三者通過zookeeper管理協調請求和轉發。這樣一個高效能的分散式訊息釋出與訂閱系統就完成了。圖上有個細節需要注意，producer到broker的過程是push，也就是有資料就推送到broker，而consumer到broker的過程是pull，是通過consumer主動去拉資料的，而不是broker把資料主動傳送到consumer端的。

這樣一個系統到底在哪裡體現出了它的高效能，我們看官網上的描述：

• Persistent messaging with O(1) disk structures that provide constant time performance even with many TB of stored messages.
• High-throughput: even with very modest hardware Kafka can support hundreds of thousands of messages per second.
• Explicit support for partitioning messages over Kafka servers and distributing consumption over a cluster of consumer machines while maintaining per-partition ordering semantics.
• Support for parallel data load into Hadoop.

至於為什麼會有O(1)這樣的效率，為什麼能有很高的吞吐量我們在後面的文章中都會講述，今天我們主要關注的還是kafka的設計理念。瞭解完了效能，我們來看下kafka到底能用來做什麼，除了我開始的時候提到的之外，我們看看kafka已經實際在跑的，用在哪些方面：

• LinkedIn - Apache Kafka is used at LinkedIn for activity stream data and operational metrics. This powers various products like LinkedIn Newsfeed, LinkedIn Today in addition to our offline analytics systems like Hadoop.

• Tumblr - http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html

• Mate1.com Inc. - Apache kafka is used at Mate1 as our main event bus that powers our news and activity feeds, automated review systems, and will soon power real time notifications and log distribution.

• Tagged - Apache Kafka drives our new pub sub system which delivers real-time events for users in our latest game - Deckadence. It will soon be used in a host of new use cases including group chat and back end stats and log collection.

• Boundary - Apache Kafka aggregates high-flow message streams into a unified distributed pubsub service, brokering the data for other internal systems as part of Boundary's real-time network analytics infrastructure.

• DataSift - Apache Kafka is used at DataSift as a collector of monitoring events and to track user's consumption of data streams in real time. http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html

• Wooga - We use Kafka to aggregate and process tracking data from all our facebook games (which are hosted at various providers) in a central location.

• AddThis - Apache Kafka is used at AddThis to collect events generated by our data network and broker that data to our analytics clusters and real-time web analytics platform.

• Urban Airship - At Urban Airship we use Kafka to buffer incoming data points from mobile devices for processing by our analytics infrastructure.

• Metamarkets - We use Kafka to collect realtime event data from clients, as well as our own internal service metrics, that feed our interactive analytics dashboards.

• SocialTwist - We use Kafka internally as part of our reliable email queueing system.

• Countandra - We use a hierarchical distributed counting engine, uses Kafka as a primary speedy interface as well as routing events for cascading counting

• FlyHajj.com - We use Kafka to collect all metrics and events generated by the users of the website.

至此你應該對kafka是一個什麼樣的系統有所體會，並能瞭解他的基本結構，還有就是他能用來做什麼。那麼接下來，我們再回到producer、consumer、broker以及zookeeper這四者的關係中來。

我們看上面的圖，我們把broker的數量減少，只有一臺。現在假設我們按照上圖進行部署：

l  Server-1 broker其實就是kafka的server，因為producer和consumer都要去連它。Broker主要還是做儲存用。

l  Server-2是zookeeper的server端，zookeeper的具體作用你可以去官網查，在這裡你可以先想象，它維持了一張表，記錄了各個節點的IP、埠等資訊（以後還會講到，它裡面還存了kafka的相關資訊）。

l  Server-3、4、5他們的共同之處就是都配置了zkClient，更明確的說，就是執行前必須配置zookeeper的地址，道理也很簡單，這之間的連線都是需要zookeeper來進行分發的。

l  Server-1和Server-2的關係，他們可以放在一臺機器上，也可以分開放，zookeeper也可以配叢集。目的是防止某一臺掛了。

簡單說下整個系統執行的順序：

1.         啟動zookeeper的server

2.         啟動kafka的server

3.         Producer如果生產了資料，會先通過zookeeper找到broker，然後將資料存放進broker

4.         Consumer如果要消費資料，會先通過zookeeper找對應的broker，然後消費。

對kafka的初步認識就寫到這裡，接下去我會寫如何搭建kafka的環境。最後感謝大神 @rockybean 的指導和幫助