- 安裝Kafka
1.1 下載解壓
下載地址：http://kafka.apache.org/downloads，如0.10.1.0版本的Kafka下載
wget http://apache.fayea.com/kafka/0.10.1.0/kafka_2.11-0.10.1.0.tgz
tar -xvf kafka_2.11-0.10.1.0.tgz
cd kafka_2.11-0.10.1.01.2 安裝Zookeeper
Kafka需要Zookeeper的監控，所以先要安裝Zookeeper，如何安裝請傳送至： hadoop、zookeeper、hbase、spark集羣環境搭建 ，安裝完成以後依次啓動各個節點
1.3 配置kafka broker集羣
我們的宗旨是面向實戰，所以拒絕安裝本地版本Kafka，來看一下Kafka集羣的配置，也很簡單
首先把Kafka解壓後的目錄複製到集羣的各臺服務器
然後修改各個服務器的配置文件：進入Kafka的config目錄，修改server.properties
# brokerid就是指各臺服務器對應的id，所以各臺服務器值不同
broker.id=0
# 端口號，無需改變
port=9092
# 當前服務器的IP，各臺服務器值不同
host.name=192.168.0.10
# Zookeeper集羣的ip和端口號
zookeeper.connect=192.168.0.10:2181,192.168.0.11:2181,192.168.0.12:2181
# 日誌目錄
log.dirs=/home/www/kafka-logs1.4 啓動Kafka
在每臺服務器上進入Kafka目錄，分別執行以下命令：
bin/kafka-server-start.sh config/server.properties &1.5 Kafka常用命令
1、新建一個主題
bin/kafka-topics.sh --create --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --replication-factor 2 --partitions 2 --topic testtest有兩個複製因子和兩個分區
2、查看新建的主題
bin/kafka-topics.sh --describe --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --topic test
其中第一行是所有分區的信息，下面的每一行對應一個分區
Leader：負責某個分區所有讀寫操作的節點
Replicas：複製因子節點
Isr：存活節點
3、查看Kafka所有的主題
bin/kafka-topics.sh --list --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181
4、在終端發送消息
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
5、在終端接收（消費）消息
bin/kafka-console-consumer.sh --zookeeper hxf:2181,cfg:2181,jqs:2181,jxf:2181,sxtb:2181 --bootstrap-server localhost:9092 --topic test --from-beginning
2 Kafka簡介
講完實戰讓我們稍微瞭解一下Kafka的一些基本入門知識
2.1 基本術語
消息
先不管其他的，我們使用Kafka這個消息系統肯定是先關注消息這個概念，在Kafka中，每一個消息由鍵、值和一個時間戳組成
主題和日誌
然後研究一下Kafka提供的核心概念——主題
Kafka集羣存儲同一類別的消息流稱爲主題
主題會有多個訂閱者（0個1個或多個），當主題發佈消息時，會向訂閱者推送記錄
針對每一個主題，Kafka集羣維護了一個像下面這樣的分區日誌：
這些分區位於不同的服務器上，每一個分區可以看做是一個結構化的提交日誌，每寫入一條記錄都會記錄到其中一個分區並且分配一個唯一地標識其位置的數字稱爲偏移量offset
Kafka集羣會將發佈的消息保存一段時間，不管是否被消費。例如，如果設置保存天數爲2天，那麼從消息發佈起的兩天之內，該消息一直可以被消費，但是超過兩天後就會被丟棄以節省空間。其次，Kafka的數據持久化性能很好，所以長時間存儲數據不是問題
如下圖所示，生產者每發佈一條消息就會向分區log寫入一條記錄的offset，而消費者就是通過offset來讀取對應的消息的，一般來說每讀取一條消息，消費者對應要讀取的offset就加1，例如最後一條讀到offset=12，那麼下條offset就爲13.由於消費者通過offset來讀取消息，所以可以重複讀取已經讀過的記錄，或者跳過某些記錄不讀
Kafka中採用分區的設計有幾個目的。一是可以處理更多的消息，不受單臺服務器的限制。Topic擁有多個分區意味着它可以不受限的處理更多的數據。第二，分區可以作爲並行處理的單元，稍後會談到這一點
分佈式
Log的分區被分佈到集羣中的多個服務器上。每個服務器處理它分到的分區。 根據配置每個分區還可以複製到其它服務器作爲備份容錯
每個分區有一個leader，零或多個follower。Leader處理此分區的所有的讀寫請求，而follower被動的複製數據。如果leader宕機，其它的一個follower會被推舉爲新的leader。 一臺服務器可能同時是一個分區的leader，另一個分區的follower。 這樣可以平衡負載，避免所有的請求都只讓一臺或者某幾臺服務器處理
生產者
生產者往某個Topic上發佈消息。生產者還可以選擇將消息分配到Topic的哪個節點上。最簡單的方式是輪詢分配到各個分區以平衡負載，也可以根據某種算法依照權重選擇分區
消費者
Kafka有一個消費者組的概念，生產者把消息發到的是消費者組，在消費者組裏面可以有很多個消費者實例，如下圖所示：
Kafka集羣有兩臺服務器，四個分區，此外有兩個消費者組A和B，消費者組A具有2個消費者實例C1-2，消費者B具有4個消費者實例C3-6
那麼Kafka發送消息的過程是怎樣的呢？
例如此時我們創建了一個主題test，有兩個分區，分別是Server1的P0和Server2的P1，假設此時我們通過test發佈了一條消息，那麼這條消息是發到P0還是P1呢，或者是都發呢？答案是隻會發到P0或P1其中之一，也就是消息只會發給其中的一個分區
分區接收到消息後會記錄在分區日誌中，記錄的方式我們講過了，就是通過offset，正因爲有這個偏移量的存在，所以一個分區內的消息是有先後順序的，即offset大的消息比offset小的消息後到。但是注意，由於消息隨機發往主題的任意一個分區，因此雖然同一個分區的消息有先後順序，但是不同分區之間的消息就沒有先後順序了，那麼如果我們要求消費者順序消費主題發的消息那該怎麼辦呢，此時只要在創建主題的時候只提供一個分區即可
講完了主題發消息，接下來就該消費者消費消息了，假設上面test的消息發給了分區P0，此時從圖中可以看到，有兩個消費者組，那麼P0將會把消息發到哪個消費者組呢？從圖中可以看到，P0把消息既發給了消費者組A也發給了B，但是A中消息僅被C1消費，B中消息僅被C3消費。這就是我們要講的，主題發出的消息會發往所有的消費者組，而每一個消費者組下面可以有很多消費者實例，這條消息只會被他們中的一個消費掉
2.2 核心API
Kafka具有4個核心API：
1.Producer API：用於向Kafka主題發送消息。
2.Consumer API：用於從訂閱主題接收消息並且處理這些消息。
3.Streams API：作爲一個流處理器，用於從一個或者多個主題中消費消息流然後爲其他主題生產消息流，高效地將輸入流轉換爲輸出流。
4.Connector API：用於構建和運行將Kafka主題和已有應用或者數據系統連接起來的可複用的生產者或消費者。例如一個主題到一個關係型數據庫的連接能夠捕獲表的任意變化。
2.3 Kafka的應用場景
Kafka用作消息系統
Kafka流的概念與傳統企業消息系統有什麼異同？
傳統消息系統有兩個模型：隊列和發佈-訂閱系統。在隊列模式中，每條服務器的消息會被消費者池中的一個所讀取；而發佈-訂閱系統中消息會廣播給所有的消費者。這兩種模式各有優劣。隊列模式的優勢是可以將消息數據讓多個消費者處理以實現程序的可擴展，然而這就導致其沒有多個訂閱者，只能用於一個進程。發佈-訂閱模式的好處在於數據可以被多個進程消費使用，但是卻無法使單一程序擴展性能
Kafka中消費者組的概念同時涵蓋了這兩方面。對應於隊列的概念，Kafka中每個消費者組中有多個消費者實例可以接收消息；對應於發佈-訂閱模式，Kafka中可以指定多個消費者組來訂閱消息
相對傳統消息系統，Kafka可以提供更強的順序保證
Kafka用作存儲系統
任何發佈消息與消費消息解耦的消息隊列其實都可以看做是用來存放發佈的消息的存儲系統，而Kafka是一個非常高效的存儲系統
寫入Kafka的數據會被存入磁盤並且複製到集羣中以容錯。Kafka允許生產者等待數據完全複製並且確保持久化到磁盤的確認應答
Kafka使用的磁盤結構擴容性能很好——不管服務器上有50KB還是50TB，Kafka的表現都是一樣的
由於能夠精緻的存儲並且供客戶端程序進行讀操作，你可以把Kafka看做是一個用於高性能、低延遲的存儲提交日誌、複製及傳播的分佈式文件系統
Kafka的流處理
僅僅讀、寫、存儲流數據是不夠的，Kafka的目的是實現實時流處理。
在Kafka中一個流處理器的處理流程是首先持續性的從輸入主題中獲取數據流，然後對其進行一些處理，再持續性地向輸出主題中生產數據流。例如一個銷售商應用，接收銷售和發貨量的輸入流，輸出新訂單和調整後價格的輸出流
可以直接使用producer和consumer API進行簡單的處理。對於複雜的轉換，Kafka提供了更強大的Streams API。可構建聚合計算或連接流到一起的複雜應用程序
流處理有助於解決這類應用面臨的硬性問題：處理無序數據、代碼更改的再處理、執行狀態計算等
Streams API所依託的都是Kafka的核心內容：使用producer和consumer API作爲輸入，使用Kafka作爲狀態存儲，在流處理實例上使用相同的組機制來實現容錯