Kafka部分：kafka的原理，解釋一下 leader 均衡機制(auto.leader.rebalance.enable=true)，高可用和負載均衡的區別
- kafka是什麼？使用場景？
kafka是一個高吞吐的分散式訊息佇列系統。特點是生產者消費者模式，先進先出（FIFO）保證順序，自己不丟資料，預設每隔7天清理資料。訊息列隊常見場景：系統之間解耦合、峰值壓力緩衝、非同步通訊。
2.kafka生產訊息、儲存訊息、消費訊息
Kafka架構是由producer（訊息生產者）、consumer（訊息消費者）、borker(kafka叢集的server，負責處理訊息讀、寫請求，儲存訊息，在kafka cluster這一層這裡，其實裡面是有很多個broker)、topic（訊息佇列/分類相當於佇列，裡面有生產者和消費者模型）、zookeeper(元資料資訊存在zookeeper中，包括：儲存消費偏移量，topic話題資訊，partition資訊) 這些部分組成。
kafka裡面的訊息是有topic來組織的，簡單的我們可以想象為一個佇列，一個佇列就是一個topic，然後它把每個topic又分為很多個partition，這個是為了做並行的，在每個partition內部訊息強有序，相當於有序的佇列，其中每個訊息都有個序號offset，比如0到12，從前面讀往後面寫。一個partition對應一個broker，一個broker可以管多個partition，比如說，topic有6個partition，有兩個broker，那每個broker就管3個partition。這個partition可以很簡單想象為一個檔案，當資料發過來的時候它就往這個partition上面append，追加就行，訊息不經過記憶體緩衝，直接寫入檔案，kafka和很多訊息系統不一樣，很多訊息系統是消費完了我就把它刪掉，而kafka是根據時間策略刪除，而不是消費完就刪除，在kafka裡面沒有一個消費完這麼個概念，只有過期這樣一個概念。
producer自己決定往哪個partition裡面去寫，這裡有一些的策略，譬如hash。consumer自己維護消費到哪個offset，每個consumer都有對應的group，group內是queue消費模型（各個consumer消費不同的partition，因此一個訊息在group內只消費一次），group間是publish-subscribe消費模型，各個group各自獨立消費，互不影響，因此一個訊息在被每個group消費一次。
3.kafka的特點
- 系統的特點：生產者消費者模型，FIFO
Partition內部是FIFO的，partition之間呢不是FIFO的，當然我們可以把topic設為一個partition，這樣就是嚴格的FIFO。
- 高效能：單節點支援上千個客戶端，百MB/s吞吐，接近網絡卡的極限
- 永續性：訊息直接持久化在普通磁碟上且效能好
直接寫到磁碟中去，就是直接append到磁盤裡去，這樣的好處是直接持久化，資料不會丟失，第二個好處是順序寫，然後消費資料也是順序的讀，所以持久化的同時還能保證順序，比較好，因為磁碟順序讀比較好。
- 分散式：資料副本冗餘、流量負載均衡、可擴充套件
分散式，資料副本，也就是同一份資料可以到不同的broker上面去，也就是當一份資料，磁碟壞掉的時候，資料不會丟失，比如3個副本，就是在3個機器磁碟都壞掉的情況下資料才會丟，在大量使用情況下看這樣是非常好的，負載均衡，可擴充套件，線上擴充套件，不需要停服務。
- 很靈活：訊息長時間持久化+Client維護消費狀態
消費方式非常靈活，第一原因是訊息持久化時間跨度比較長，一天或者一星期等，第二消費狀態自己維護消費到哪個地方了可以自定義消費偏移量。
4.kafka叢集搭建
- 上傳kafka_2.10-0.8.2.2.tgz包到三個不同節點上，解壓。
- 配置../ kafka_2.10-0.8.2.2/config/server.properties檔案
節點編號：（不同節點按0,1,2,3整數來配置）
真實資料儲存位置：
zookeeper的節點：
- 啟動zookeeper叢集。
- 三個節點上，啟動kafka:
|
bin/kafka-server-start.sh config/server.properties |
最好使用自己寫的指令碼啟動，將啟動命令寫入到一個檔案：
|
nohup bin/kafka-server-start.sh config/server.properties > kafka.log 2>&1 & 指令碼附件： （放 在與bin同一級別下，注意建立後要修改許可權：chmod 755 startkafka.sh） |
5.相關命令：
建立topic：
|
./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --create --topic topic2017 --partitions 3 --replication-factor 3 |
用一臺節點控制檯來當kafka的生產者：
|
./kafka-console-producer.sh --topic topic2017 --broker-list node1:9092,node2:9092,node3:9092 |
用另一臺節點控制檯來當kafka的消費者：
|
./kafka-console-consumer.sh --zookeeper node3:2181,node4:2181,node5:2181 --topic topic2017 |
檢視kafka中topic列表:
|
./kafka-topics.sh --list --zookeeper node3:2181,node4:2181,node5:2181 |
檢視kafka中topic的描述：
|
./kafka-topics.sh --describe --zookeeper node3:2181,node4:2181,node5:2181 --topic topic2017 注意：ISR是檢查資料的完整性有哪些個節點。 |
檢視zookeeper中topic相關資訊：
|
啟動zookeeper客戶端： ./zkCli.sh 檢視topic相關資訊： ls /brokers/topics/ 檢視消費者相關資訊： ls /consumers |
6.
- 刪除kafka中的資料。
- ：在kafka叢集中刪除topic，當前topic被標記成刪除。
|
./kafka-topics.sh --zookeeper node3:2181,node4:2181,node5:2181 --delete --topic t1205 |
在每臺broker節點上刪除當前這個topic對應的真實資料。
-
- ：進入zookeeper客戶端，刪除topic資訊
|
rmr /brokers/topics/t1205 |
-
- ：刪除zookeeper中被標記為刪除的topic資訊
|
rmr /admin/delete_topics/t1205 |
7.kafka的leader的均衡機制
當一個broker停止或者crashes時，所有本來將它作為leader的分割槽將會把leader轉移到其他broker上去，極端情況下，會導致同一個leader管理多個分割槽，導致負載不均衡，同時當這個broker重啟時，如果這個broker不再是任何分割槽的leader,kafka的client也不會從這個broker來讀取訊息，從而導致資源的浪費。
kafka中有一個被稱為優先副本（preferred replicas）的概念。如果一個分割槽有3個副本，且這3個副本的優先級別分別為0,1,2，根據優先副本的概念，0會作為leader 。當0節點的broker掛掉時，會啟動1這個節點broker當做leader。當0節點的broker再次啟動後，會自動恢復為此partition的leader。不會導致負載不均衡和資源浪費，這就是leader的均衡機制。
在配置檔案conf/ server.properties中配置開啟（預設就是開啟）：
|
auto.leader.rebalance.enable true |
解釋一下 leader 均衡機制(auto.leader.rebalance.enable=true)：
當 partition 1 的 leader，就是 broker.id = 1 的節點掛掉後，那麼 leader 0 或 leader 2 成為 partition 1 的 leader，那麼 leader 0 或 leader 2 會管理兩個 partition 的讀寫，效能會下 降，當 leader 1 重新啟動後，如果開啟了 leader 均衡機制，那麼 leader 1 會重新成為 partition 1 的 leader，降低 leader 0 或 leader 2 的負載
高可用和負載均衡的區別：
高可用和負載均衡的相同點都是當一個掛了的時候，另一個起來頂替，保證系統能夠正常執行
區別在於：
高可用是主備模型，向master和backup，namenode就是，HBASE也是
負載均衡一般是多主模型，每個都分擔流向，向zookeeper就是這種模型