在我們大量使用分佈式數據庫、分佈式計算集羣的時候，是否會遇到這樣的一些問題：
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端的。
這樣一個系統到底哪裏體現出了它的高性能，如官網上所述，翻譯如下：
（1）數據在磁盤上存取代價爲O(1)。一般數據在磁盤上是使用BTree存儲的，存取代價爲O（lgn）。
（2）高吞吐率。即使在普通的節點上每秒鐘也能處理成百上千的message。
（3）顯式分佈式，即所有的producer、broker和consumer都會有多個，均爲分佈式的。
（4）支持數據並行加載到Hadoop中。
等等
至此你應該對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，然後消費。