終于可以寫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.
至于為什麼會有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.
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.
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也可以配叢集。目的是防止某一台挂了。
簡單說下整個系統運作的順序：
啟動zookeeper的server
啟動kafka的server
Producer如果生産了資料，會先通過zookeeper找到broker，然後将資料存放進broker
Consumer如果要消費資料，會先通過zookeeper找對應的broker，然後消費。
轉自：http://blog.csdn.net/u014075753/article/details/52355737
本文轉自飛奔的小GUI部落格51CTO部落格，原文連結http://blog.51cto.com/9237101/1917090如需轉載請自行聯系原作者
ziwenzhou