1、Kafka是什麼

Kafka是最初由Linkedin公司開發，是一個分散式、分割槽的、多副本的、多訂閱者，基於zookeeper協調的分散式日誌系統(也可以當做MQ系統)，常見可以用於web/nginx日誌、訪問日誌，訊息服務等等，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源專案。

2、產生背景

Kafka是一個訊息系統，用作LinkedIn的活動流（Activity Stream）和運營資料處理管道（Pipeline）的基礎。活動流資料是幾乎所有站點在對其網站使用情況做報表時都要用到的資料中最常規的部分。活動資料包括頁面訪問量（Page View）、被檢視內容方面的資訊以及搜尋情況等內容。這種資料通常的處理方式是先把各種活動以日誌的形式寫入某種檔案，然後週期性地對這些檔案進行統計分析。運營資料指的3是伺服器的效能資料（CPU、IO使用率、請求時間、服務日誌等等資料)。運營資料的統計方法種類繁多。

3、架構圖

4、基本概念

1、Broker

Kafka叢集包含一個或多個伺服器，這種伺服器被稱為broker。broker端不維護資料的消費狀態，提升了效能。直接使用磁碟進行儲存，線性讀寫，速度快：避免了資料在JVM記憶體和系統記憶體之間的複製，減少耗效能的建立物件和垃圾回收。

2、Producer

訊息生產者，釋出訊息到Kafka broker

3、Consumer

訊息消費者，從Kafka Broker讀取訊息的客戶端，consumer從broker拉取(pull)資料並進行處理。相比較於ActiveMQ來講，使用者使用kafka時可以根據自己的消費速度的快慢來自主選擇從Broker拉取訊息的節奏，而ActiveMQ則是把Broker上的訊息主動推送到客戶端，各有優勢。

4、Topic

每條釋出到Kafka叢集的訊息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的訊息分開儲存，邏輯上一個Topic的訊息雖然保存於一個或多個broker上但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處）

5、Partition

一個Topic可以認為是一類訊息，每個topic將被分成多個partition(區),每個partition在儲存層面是append log檔案。任何釋出到此partition的訊息都會被直接追加到log檔案的尾部，每條訊息在檔案中的位置稱為offset（偏移量），offset為一個long型數字，它是唯一標記一條訊息。它唯一的標記一條訊息。kafka並沒有提供其他額外的索引機制來儲存offset，因為在kafka中幾乎不允許對訊息進行“隨機讀寫”。

其實，Topic在邏輯上可以被認為是一個queue，每條消費都必須指定它的Topic，可以簡單理解為必須指明把這條訊息放進哪個queue裡。為了使得Kafka的吞吐率可以線性提高，物理上把Topic分成一個或多個Partition，每個Partition在物理上對應一個資料夾，該資料夾下儲存這個Partition的所有訊息和索引檔案。若建立topic1和topic2兩個topic，且分別有13個和19個分割槽，則整個叢集上會相應會生成共32個資料夾（本文所用叢集共8個節點，此處topic1和topic2 replication-factor均為1）。

5、適用場景

1、Messaging

對於一些常規的訊息系統,kafka是個不錯的選擇;partitons/replication和容錯,可以使kafka具有良好的擴充套件性和效能優勢.不過到目前為止,我們應該很清楚認識到,kafka並沒有提供JMS中的"事務性""訊息傳輸擔保(訊息確認機制)""訊息分組"等企業級特性;kafka只能使用作為"常規"的訊息系統,在一定程度上,尚未確保訊息的傳送與接收絕對可靠(比如,訊息重發,訊息傳送丟失等)

2、Website activity tracking

kafka可以作為"網站活性跟蹤"的最佳工具;可以將網頁/使用者操作等資訊傳送到kafka中.並實時監控,或者離線統計分析等

3、Metrics

Kafka通常被用於可操作的監控資料。這包括從分散式應用程式來的聚合統計用來生產集中的運營資料提要。

4、Log Aggregation

kafka的特性決定它非常適合作為"日誌收集中心";application可以將操作日誌"批量""非同步"的傳送到kafka叢集中,而不是儲存在本地或者DB中;kafka可以批量提交訊息/壓縮訊息等,這對producer端而言,幾乎感覺不到效能的開支.此時consumer端可以使hadoop等其他系統化的儲存和分析系統