#（一）單機版安裝

此部分不可用於生產，但新接觸kafka時，可以先有個感性的認識
Step 1: 下載Kafka下載最新的版本並解壓.

Step 2: 啟動服務
Kafka用到了Zookeeper，所有首先啟動Zookper，下面簡單的啟用一個單例項的Zookkeeper服務。可以在命令的結尾加個&符號，這樣就可以啟動後離開控制檯。

現在啟動Kafka:

Step 3: 建立 topic

建立一個叫做“test”的topic，它只有一個分割槽，一個副本。

可以通過list命令檢視建立的topic:

除了手動建立topic，還可以配置broker讓它自動建立topic.
Step 4:傳送訊息.
Kafka 使用一個簡單的命令列producer，從檔案中或者從標準輸入中讀取訊息併傳送到服務端。預設的每條命令將傳送一條訊息。

執行producer並在控制檯中輸一些訊息，這些訊息將被髮送到服務端：

ctrl+c可以退出傳送。
預設情況下，日誌資料會被放置到/tmp/kafka-logs中，每個分割槽一個目錄
Step 5: 啟動consumer

你在一個終端中執行consumer命令列，另一個終端中執行producer命令列，就可以在一個終端輸入訊息，另一個終端讀取訊息。
這兩個命令都有自己的可選引數，可以在執行的時候不加任何引數可以看到幫助資訊。

#（二）叢集安裝

注意，必須先搭建zookeeper叢集

1、使用3臺機器搭建Kafka叢集：
192.168.169.92 gdc-dn01-test
192.168.169.93 gdc-dn02-test
192.168.169.94 gdc-dn03-test

2、在安裝Kafka叢集之前，這裡沒有使用Kafka自帶的Zookeeper，而是獨立安裝了一個Zookeeper叢集，也是使用這3臺機器，保證Zookeeper叢集正常執行。
3、首先，在gdc-dn01-test上準備Kafka安裝檔案，執行如下命令：

4、修改配置檔案kafka/config/server.properties，修改如下內容：

這裡需要說明的是，預設Kafka會使用ZooKeeper預設的/路徑，這樣有關Kafka的ZooKeeper配置就會散落在根路徑下面，如果 你有其他的應用也在使用ZooKeeper叢集，檢視ZooKeeper中資料可能會不直觀，所以強烈建議指定一個chroot路徑，直接在 zookeeper.connect配置項中指定：

而且，需要手動在ZooKeeper中建立路徑/kafka，使用如下命令連線到任意一臺 ZooKeeper伺服器：

5、然後，將配置好的安裝檔案同步到其他的dn02、dn03節點上：

6、最後，在dn02、dn03節點上配置修改配置檔案kafka/config/server.properties內容如下所示：

因為Kafka叢集需要保證各個Broker的id在整個叢集中必須唯一，需要調整這個配置項的值（如果在單機上，可以通過建立多個Broker程式來模擬分散式的Kafka叢集，也需要Broker的id唯一，還需要修改一些配置目錄的資訊）。

7、在叢集中的dn01、dn02、dn03這三個節點上分別啟動Kafka，分別執行如下命令：

可以通過檢視日誌，或者檢查程式狀態，保證Kafka叢集啟動成功。

8、建立一個名稱為my-replicated-topic5的Topic，5個分割槽，並且複製因子為3，執行如下命令：

9、檢視建立的Topic，執行如下命令：

結果資訊如下所示：

1 Partition： 分割槽
2 Leader ： 負責讀寫指定分割槽的節點
3 Replicas ： 複製該分割槽log的節點列表
4 Isr ： “in-sync” replicas，當前活躍的副本列表（是一個子集），並且可能成為Leader
我們可以通過Kafka自帶的bin/kafka-console-producer.sh和bin/kafka-console-consumer.sh指令碼，來驗證演示如果釋出訊息、消費訊息。

11、在一個終端，啟動Producer，並向我們上面建立的名稱為my-replicated-topic5的Topic中生產訊息，執行如下指令碼：

12、在另一個終端，啟動Consumer，並訂閱我們上面建立的名稱為my-replicated-topic5的Topic中生產的訊息，執行如下指令碼：

可以在Producer終端上輸入字串訊息行，就可以在Consumer終端上看到消費者消費的訊息內容。
也可以參考Kafka的Producer和Consumer的Java API，通過API編碼的方式來實現訊息生產和消費的處理邏輯。

#（三）叢集啟停操作

1、啟動叢集

2、停止叢集

3、重啟
沒有專用指令碼，先停後啟即可

注：當然也可以使用kill命令來關閉，但使用指令碼有以下好處：
(1)It will sync all its logs to disk to avoid needing to do any log recovery when it restarts (i.e. validating the checksum for all messages in the tail of the log). Log recovery takes time so this speeds up intentional restarts.
(2)It will migrate any partitions the server is the leader for to other replicas prior to shutting down. This will make the leadership transfer faster and minimize the time each partition is unavailable to a few milliseconds.

#（四）topic相關的操作

1、建立topic

（1）zookeeper指定其中一個節點即可，叢集之間會自動同步。
（2）–replication-factor 2 –partitions 3理論上應該是可選引數，但此指令碼必須寫這2個引數。
（3）還可以使用–config 來指定topic的某個具體引數，以代替配置檔案中的引數。如：
bin/kafka-topics.sh –create –zookeeper 192.168.172.98:2181/kafka –replication-factor 2 –partitions 3 –topic test_topic retention.bytes＝3298534883328
指定了某個topic最大的保留日誌量，單位是位元組。

2、檢視全部topic
bin/kafka-topics.sh –list –zookeeper 192.168.172.98:2181/kafka

3、檢視某個topic的詳細資訊

（1）第一行列出了這個topic的總體情況，如topic名稱，分割槽數量，副本數量等。
（2）第二行開始，每一行列出了一個分割槽的資訊，如它是第幾個分割槽，這個分割槽的leader是哪個broker，副本位於哪些broker，有哪些副本處理同步狀態。

4、啟動一個console producer，用於在console中模擬輸入訊息

5、啟動一個console consumer，用於模擬接收訊息，並在console中輸出

此指令碼可以用於驗證一個topic的資料情況，看訊息是否正常流入等。

6、刪除一個topic

（1）配置檔案中必須delete.topic.enable=true，否則只會標記為刪除，而不是真正刪除。
（2）執行此指令碼的時候，topic的資料會同時被刪除。如果由於某些原因導致topic的資料不能完全刪除（如其中一個broker down了）,此時topic只會被marked for deletion，而不會真正刪除。此時建立同名的topic會有衝突。

7、修改topic
使用—-alert原則上可以修改任何配置，以下列出了一些常用的修改選項：
（1）改變分割槽數量

（2）增加、修改或者刪除一個配置引數

#（五）某個broker掛掉，本機器可重啟

【結論】如果一個broker掛掉，且可以重啟則處理步驟如下：
（1）重啟kafka程式
（2）執行rebalance（由於已經設定配置項自動執行balance，因此此步驟一般可忽略）

詳細分析見下面操作過程。
1、topic的情況

叢集中有4臺機器，id為【2-5】,topic 有3個分割槽，每個分割槽2個副本，leader分別位於2，3，5中。

2、模擬機器down，kill掉程式
分割槽0的leader位於id=5的broker中，kill掉這臺機器的kafka程式

3、再次檢視topic的情況

可以看到，分割槽0的leader已經移到id=2的機器上了，它的副本位於2，5這2臺機器上，但處於同步狀態的只有id=2這臺機器。

4、重啟kafka程式

5、再次檢視狀態

發現分割槽0的2個副本都已經處於同步狀態，但leader依然為id=2的broker。

6、執行leader平衡
詳見leader的平衡部分。

如果配置檔案中

則此步驟不需要執行。

7、重新檢視topic

此時leader已經回到了id=5的broker，一切恢復正常。

#（六）某個broker掛掉且無法重啟，需要其它機器代替

【結論】當一個broker掛掉，需要換機器時，採用以下步驟：
1、將新機器kafka配置檔案中的broker.id設定為與原機器一樣
2、啟動kafka，注意kafka儲存資料的目錄不會自動建立，需要手工建立

詳細分析過程如下：
1、初始化機器，主要包括使用者建立，kafka檔案的複製等。

2、修改config/server.properties檔案
注意，只需要修改一個配置broker.id，且此配置必須與掛掉的那臺機器相同，因為kafka是通過broker.id來區分叢集中的機器的。此處設為

3、檢視topic的當前狀態

當前topic有3個分割槽，其中分割槽1的leader位於id=5的機器上。

4、關掉id=5的機器
kill -9 ** 用於模擬機器突然down
或者：

用於正常關閉

5、檢視topic的狀態

可見，topic的分割槽0的leader已經遷移到了id=2的機器上，且處於同步的機器只有一個了。

6、啟動新機器

7、再看topic的狀態

id=5的機器也處於同步狀態了，但還需要將leader恢復到這臺機器上。

8、執行leader平衡
詳見leader的平衡部分。

如果配置檔案中

則此步驟不需要執行。

9、done

所有內容都恢復了

#（七）擴容

將一臺機器加入kafka叢集很容易，只需要為它分配一個獨立的broker id，然後啟動它即可。但是這些新加入的機器上面並沒有任何的分割槽資料，所以除非將現有資料移動這些機器上，否則它不會做任何工作，直到建立新topic。因此，當你往叢集加入機器時，你應該將其它機器上的一部分資料往這臺機器遷移。
資料遷移的工作需要手工初始化，然後自動完成。它的原理如下：當新機器起來後，kafka將其它機器的一些分割槽複製到這個機器上，並作為follower，當這個新機器完成複製併成為in-sync狀態後，那些被複制的分割槽的一個副本會被刪除。（都不會成為leader?)

1、將新機器kafka配置檔案中的broker.id設定為與原機器一樣
2、啟動kafka，注意kafka儲存資料的目錄不會自動建立，需要手工建立
此時新建的topic都會優先分配leader到新增的機器上，但原有的topic不會將分割槽遷移過來。
3、資料遷移，請見資料遷移部分。

#（八）資料遷移

以下步驟用於將現有資料遷移到新的broker中，假設需要將test_topic與streaming_ma30_sdc的全部分割槽遷移到新的broker中（id 為6和7）
1、建立一個json檔案，用於指定哪些topic將被遷移過去
cat topics-to-move.json

注意全形，半形符號，或者中文引號之類的問題。

2、先generate遷移後的結果，檢查一下是不是你要想的效果

分別列出了當前的狀態以及遷移後的狀態。
把這2個json分別儲存下來，第一個用來萬一需要roll back的時候使用，第二個用來執行遷移。

3、執行遷移

4、檢視遷移過程

5、當所有遷移的完成後，檢視一下結果是不是你想要的

完成

以上步驟將整個topic遷移，也可以只遷移其中一個或者多個分割槽。
以下將test_topic的分割槽1移到broker id為2，3的機器,分割槽2移到broker id為4,5的機器.
【其實還是整個topic遷移好一點，不然準備遷移檔案會很麻煩】

1、準備遷移配置檔案
cat custom-reassignment.json

3、執行遷移

4、檢視遷移過程

5、檢視遷移結果

#（九）機器下線

當一個機器下線時，kafka並不會自動將這臺機器上的副本遷移到其它機器上，因此，我們需要手工進行遷移。這個過程會相當的無聊，kafka打算在0.8.2版本中新增此特性。
有了嗎？再找找。如果只是替換機器則不會有這個問題。

#（十）增加副本數量Increasing replication factor

Increasing the replication factor of an existing partition is easy. Just specify the extra replicas in the custom reassignment json file and use it with the –execute option to increase the replication factor of the specified partitions.
For instance, the following example increases the replication factor of partition 0 of topic foo from 1 to 3. Before increasing the replication factor, the partition’s only replica existed on broker 5. As part of increasing the replication factor, we will add more replicas on brokers 6 and 7.

The first step is to hand craft the custom reassignment plan in a json file-

cat increase-replication-factor.json
{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5,6,7]}]}

Then, use the json file with the –execute option to start the reassignment process-
> bin/kafka-reassign-partitions.sh –zookeeper localhost:2181 –reassignment-json-file increase-replication-factor.json –execute
Current partition replica assignment

{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5]}]}

Save this to use as the –reassignment-json-file option during rollback
Successfully started reassignment of partitions
{“version”:1,
“partitions”:[{“topic”:”foo”,”partition”:0,”replicas”:[5,6,7]}]}
The –verify option can be used with the tool to check the status of the partition reassignment. Note that the same increase-replication-factor.json (used with the –execute option) should be used with the –verify option

bin/kafka-reassign-partitions.sh –zookeeper localhost:2181 –reassignment-json-file increase-replication-factor.json –verify
Status of partition reassignment:
Reassignment of partition [foo,0] completed successfully
You can also verify the increase in replication factor with the kafka-topics tool-
> bin/kafka-topics.sh –zookeeper localhost:2181 –topic foo –describe
Topic:foo PartitionCount:1 ReplicationFactor:3 Configs:
Topic: foo Partition: 0 Leader: 5 Replicas: 5,6,7 Isr: 5,6,7

#（十一）leader的平衡

當一個broker down掉時，所有本來將它作為leader的分割槽會被將leader轉移到其它broker。這意味著當這個broker重啟時，它將不再擔任何分割槽的leader，kafka的client也不會從這個broker來讀取訊息，導致資源的浪費。
為了避免這種情況的發生，kafka增加了一個標記：優先副本（preferred replicas）。如果一個分割槽有3個副本，且這3個副本的優先順序別分別為1，5，9，則1會作為leader。為了使kafka叢集恢復預設的leader，需要執行以下命令：

或者可以設定以下配置項，leader 會自動執行balance：

這配置預設即為空，但需要經過一段時間後才會觸發，約半小時。