kafka特點：高性能，持久化，多副本，橫向擴展能力
一.名詞理解
producer和consumer：生產者，消費者就不多說了
1.kafka cluster：kafka集羣簇
2.Broker：消息中間件處理節點，一個kafka節點就是一個broker,每個服務器上有一個或多個kafka的節點，多個broker組成一個kafka集羣(不同的broker之間，可以聯繫)
3.Topic：消息主題，kafka根據topic對消息進行分類，發佈到kafka集羣的每條消息都要指定一個Topic
4.Partition：Topic的分區，每個topic可以有多個partition分區，分區的作用是做負載，提高kafka的吞吐量。同一個topic在不同的分區的數據是不重複的，partition的表現形式就是一個一個的文件夾
5.Leader:主分區，如上圖，生產者優先把消息存儲到相應topic的主分區下
6.Follower:副本分區
7.Zookeeper：分佈式協調系統
二.爲什麼kafka做分區
1、方便擴展。因爲一個topic可以有多個partition，所以我們可以通過擴展機器去輕鬆的應對日益增長的數據量。
2、提高併發。以partition爲讀寫單位，可以多個消費者同時消費數據，提高了消息的處理效率。
三.如何保證producer向kafka寫入消息的時候，怎麼保證消息不丟失
1.通過ACK應答機制。在生產者向隊列寫入數據的時候可以設置參數來確定是否確認kafka接收到數據，這個參數可設置的值爲0、1、-1
0代表producer往集羣發送數據不需要等到集羣的返回，不確保消息發送成功。安全性最低但是效率最高。
1代表producer往集羣發送數據只要leader應答就可以發送下一條，只確保leader發送成功。
-1代表producer往集羣發送數據需要所有的follower都完成從leader的同步纔會發送下一條，確保leader發送成功和所有的副本都完成備份。安全性最高，但是效率最低。
最後要注意的是，如果往不存在的topic寫數據，能不能寫入成功呢？kafka會自動創建topic，分區和副本的數量根據默認配置都是1。
四.partition結構
Partition在服務器上的表現形式就是一個一個的文件夾，每個partition的文件夾下面會有多組segment文件，每組segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中沒有）三個文件， log文件就實際是存儲message的地方，而index和timeindex文件爲索引文件，用於檢索消息
4.1. Message結構：包含消息體，消息大小，offest，壓縮類型等，重點3個：
1.offset：offset是一個佔8byte的有序id號，它可以唯一確定每條消息在parition內的位置！
2.消息大小：消息大小佔用4byte，用於描述消息的大小。
3.消息體：消息體存放的是實際的消息數據（被壓縮過），佔用的空間根據具體的消息而不一樣
五.存儲策略
無論消息是否被消費，kafka都會保存所有的消息。那對於舊數據有什麼刪除策略呢？
1、 基於時間，默認配置是168小時（7天）。
2、 基於大小，默認配置是1073741824。
需要注意的是，kafka讀取特定消息的時間複雜度是O(1)，所以這裏刪除過期的文件並不會提高kafka的性能！
六。消費數據
1.消息存儲在log文件後，消費者就可以進行消費了。Kafka採用的是點對點的模式，消費者主動的去kafka集羣拉取消息，與producer相同的是，消費者在拉取消息的時候也是找leader去拉取。
2.多個消費者可以組成一個消費者組（consumer group），每個消費者組都有一個組id！同一個消費組者的消費者可以消費同一topic下不同分區的數據，但是不會組內多個消費者消費同一分區的數據
七。後臺配置優化（/data/kafka/config/）
1.配置文件server.properties
# broker處理消息的最大線程數
num.network.threads=3 （建議cpu核數加1.）
# broker處理磁盤IO的線程數
num.io.threads=8 （建議cpu核數2倍）
#日誌保留默認168小時=7天，建議3天即可
log.retention.hours=168
#單個segment文件大小，默認1G=1073741824byte
log.segment.bytes=1073741824
#間隔多久檢查一次segment文件
log.retention.check.interval.ms=300000
# 每當producer寫入10000條消息時，刷數據到磁盤
log.flush.interval.messages=10000
# 每間隔1秒鐘時間，刷數據到磁盤
log.flush.interval.ms=1000
#日誌路徑及是否可以清空日誌（true,符合條件即清理）
log.dirs=/data/kafka/logs
delete.topic.enable=true
#節點id及分區數量
num.partitions=1
broker.id=0
八.使用JMX監控kafka性能
1.在./kafka/bin/kafka-run-class.sh裏，加入JMX_PORT=9999 （每個broker都需要加）
2.重啓kafka集羣（可以先kill，然後啓動，啓動要加參數：./kafka-server-start.sh -daemon /data/kafka/config/server.properties）
3.在本地cmd中執行jconsole.exe(沒配置環境變量的，去相應目錄下手動運行)
4.登錄時注意端口號，是上面“JMX_PORT=9999”的端口號，9999；在Mbean下查看kafka指標信息
5.重點監控指標：
消息入站速率（消息數）
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec
消息入站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
消息出站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec
Leader副本數
kafka.server:type=ReplicaManager,name=LeaderCount
Partition數量
kafka.server:type=ReplicaManager,name=PartitionCount
同步失效的副本數
kafka.server:type=ReplicaManager, name=UnderReplicatedPartitions
解釋：這個UnderReplicatedPartitions是一個Broker級別的指標，指的是leader副本在當前Broker上且具有失效副本的分區的個數，也就是說這個指標可以讓我們感知失效副本的存在以及波及的分區數量。這一類分區也就是文中篇頭所說的同步失效分區，即under-replicated分區。
如果集羣中存在Broker的UnderReplicatedPartitions頻繁變動，或者處於一個穩定的大於0的值（這裏特指沒有Broker下線的情況）時，一般暗示着集羣出現了性能問題