Kafka架構設計：分布式發布訂閱消息系統

【http://www.oschina.net/translate/kafka-design】（較長：很詳細的講解）

【我們為什么要搭建該系統】
用作LinkedIn的活動流（activity stream）和運營數據處理管道（pipeline）的基礎。
作為多種類型的數據管道（data pipeline）和消息系統使用。

活動流數據是所有站點在對其網站使用情況做報表時要用到的數據中最常規的部分。活動數據包括頁面訪問量（page view）、被查看內容方面的信息以及搜索情況等內容。這種數據通常的處理方式是先把各種活動以日志的形式寫入某種文件，然后周期性地對這些文件進行統計分析。

運營數據指的是服務器的性能數據（CPU、IO使用率、請求時間、服務日志等等數據)。運營數據的統計方法種類繁多。

【活動流數據的特點】
這種由不可變（immutable）的活動數據組成的高吞吐量數據流代表了對計算能力的一種真正的挑戰，因其數據量很容易就可能會比網站中位于第二位的數據源的數據量大10到100倍。
傳統的日志文件統計分析對報表和批處理這種離線處理的情況來說，是一種很不錯且很有伸縮性的方法；但是這種方法對于實時處理來說其時延太大，而且還具有較高的運營復雜度。另一方面，現有的消息隊列系統（messaging and queuing system）卻很適合于在實時或近實時（near-real-time）的情況下使用，但它們對很長的未被處理的消息隊列的處理很不給力，往往并不將數據持久化作為首要的事情考慮。這樣就會造成一種情況，就是當把大量數據傳送給Hadoop這樣的離線系統后， 這些離線系統每個小時或每天僅能處理掉部分源數據。Kafka的目的就是要成為一個隊列平臺，僅僅使用它就能夠既支持離線又支持在線使用這兩種情況。
Kafka支持非常通用的消息語義（messaging semantics）。盡管我們這篇文章主要是想把它用于活動處理，但并沒有任何限制性條件使得它僅僅適用于此目的。

?

更多內容，未完待續...