???????? 官方描述(0.8)：Kafka? is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.
即Kafka是一個分布式的，基于分區(qū)的，多副本的消息系統(tǒng)，它以獨特的設(shè)計理念，提供了消息傳遞的功能。
????????傳統(tǒng)的消息系統(tǒng)通常有兩種模型，一個是“排隊（queuing
）”，一個是“發(fā)布-訂閱（publish-subscribe）。
對于排隊模型（消息隊列），允許有多個消費者（consumer）實例，且多個消費者實例可以分別處理隊列中不相同的數(shù)據(jù)，所以方便消費端能力擴(kuò)展。但隊列中一條消息只能被一個消費者消費，一旦消息被某個消費者讀到，消息就會消失，其他消費者將不能讀取到該消息。對于發(fā)布-訂閱模型，其也可以有多個消費者，不同的是它是以廣播方式，一條消息可以被多個消費者消費，由于是消息廣播方式，所以不便于消費端能力擴(kuò)展。而Kafka的消息既可以被多次消費，消費者能力也可以很容易擴(kuò)展，具體原理后續(xù)再做解釋。
????????“發(fā)布-訂閱”模型，還有個特點：數(shù)據(jù)（消息）的發(fā)送者（發(fā)布者）不會把數(shù)據(jù)直接發(fā)給接收者。
????????對于簡單的或者某些系統(tǒng)的前期需求，普通系統(tǒng)架構(gòu)即可滿足，但隨著時間推移，或者需求的更復(fù)雜化，架構(gòu)就需要做些優(yōu)化調(diào)整。比如前端應(yīng)用服務(wù)（FrontendServer）的“指標(biāo)度量消息”系統(tǒng)，前期我們可以直接在應(yīng)用服務(wù)和儀表盤服務(wù)（MetricsServer）間建立連接，然后通過這個連接發(fā)送度量指標(biāo)，如圖一：
????????但隨著需求增多，“直連架構(gòu)”會變得一團(tuán)糟。比如當(dāng)需要分析更長時間段的度量指標(biāo)時，此時儀表盤服務(wù)不能滿足需求，于是我們引入一個新的服務(wù)--指標(biāo)分析服務(wù)（MetricAnalysis）來處理長時間段的度量指標(biāo)，此時我們的應(yīng)用服務(wù)需要在其與指標(biāo)分析服務(wù)間再建立一條鏈路。當(dāng)類似需求越來越多，鏈路也會越來越多，最終系統(tǒng)將會比較復(fù)雜、混亂，如圖二：
????????此時，我們最好對系統(tǒng)架構(gòu)做些調(diào)整，讓其“看起來更舒服些”。比如我們可以建立一個獨立的服務(wù)來接收其他應(yīng)用系統(tǒng)的度量指標(biāo)，并為其他系統(tǒng)提供查詢的服務(wù)，如此“指標(biāo)度量”系統(tǒng)架構(gòu)復(fù)雜度就會降低很多，如圖三：
????????此時的“指標(biāo)度量”系統(tǒng)，就可歸屬于“發(fā)布-訂閱消息”系統(tǒng)。除了“指標(biāo)度量”系統(tǒng)外，也許我們還會需要“日志記錄”、“用戶行為追蹤”等系統(tǒng)，我們都可以采用這種方式來解耦信息的發(fā)布和訂閱者，如圖四：
????????如此方式比使用“直連”要好很多，但也有一些不好地方，比如多個發(fā)布-訂閱系統(tǒng)間有很多地方功能重復(fù)，公司也需要維護(hù)多個數(shù)據(jù)隊列系統(tǒng)，此時更好的方式是，我們做一個統(tǒng)一的、集中式的系統(tǒng)，他可以用來發(fā)布通用類型的數(shù)據(jù)，并且其規(guī)模可以隨著公司業(yè)務(wù)的增長而增長。而Kafka就是可以用于解決這個問題的一個基于“發(fā)布-訂閱”的消息系統(tǒng)。
參考:
《Kafka The Definitive Guide》
http://kafka.apache.org/documentation/#introduction
