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

【我們?yōu)槭裁匆罱ㄔ撓到y(tǒng)】
用作LinkedIn的活動流（activity stream）和運(yùn)營數(shù)據(jù)處理管道（pipeline）的基礎(chǔ)。
作為多種類型的數(shù)據(jù)管道（data pipeline）和消息系統(tǒng)使用。

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

運(yùn)營數(shù)據(jù)指的是服務(wù)器的性能數(shù)據(jù)（CPU、IO使用率、請求時間、服務(wù)日志等等數(shù)據(jù))。運(yùn)營數(shù)據(jù)的統(tǒng)計方法種類繁多。

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

?

更多內(nèi)容，未完待續(xù)...

轉(zhuǎn)載于:https://www.cnblogs.com/lsx1993/p/4627400.html

總結(jié)

以上是生活随笔為你收集整理的Kafka架构设计：分布式发布订阅消息系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。