1.kafka整體概念
不僅僅是一個消息中間件， 可以看作是一個流平臺、可以訂閱發佈數據流，並且把數據保存起來進行處理。是一個分佈式的以集羣形式運行的中間件。kafka的低延時所以被用來作爲核心的業務應用上。消息天生持久化：數據存儲平臺，流平臺。主要用在數據的流處理上，所以因爲他的低延時被主要用在覈心的業務應用上。
1.1kafka內部相關的概念
1）消息：可以包括鍵的一個字節數組
批次：爲了提高效率，消息是被分批次寫入broke的（同一個主題中消息），消息也是可以被壓縮。
主題：個人理解是和topick關聯的，一個topick對應一個主題。
分區：一個主題可以被分爲許多分區，每個分區內的消息是以追加的形式加入到消息中的。所以單個分區內的消息肯定是順序 的。分區的個數是自定義的，broke接受到消息後就可以根據內部的分區器來對消息進行映射（主要是用來實現數據的冗餘和伸縮性）
生產者：生產者默認情況下把消息均衡分佈到主題的所有分區上，如果需要指定分區，則需要使用消息裏的消息鍵和分區器。
消費者：消費者訂閱主題，一個或者多個，並且按照消息的生成順序讀取。消費者通過檢查所謂的偏移量來區分消息是否讀取過。
偏移量：移量是一種元數據，一個不斷遞增的整數值，創建消息的時候，Kafka會把他加入消息。在一個分區裏，每個消息的偏移量是唯一的。每個分區最後讀取的消息偏移量會保存到Zookee
消費者羣組：groupID。一個主題可以被多個消費者羣組消費
消費者羣組和partition之間的關係：一個分區只可以被一個消費者羣組裏面一個consumer消費，一個消費者羣組裏的consumer可以消費多個分區。個人理解這樣的優點：可以保證一個消費者羣組內的消費者對消息的無重複消費，提高consumer消費的效率。
在這裏有個疑問：偏移量一個分區只有一個，但是如果不同的消費者羣組裏面的consumer消費同一個分區的話，難道使用的是偏移量是一個嗎？
broke和集羣
2.kafka相關文件的配置
配置文件放在Kafka目錄下的config目錄中，主要是server.properties文件
broker.id
在單機時無需修改，但在集羣下部署時往往需要修改。它是個每一個broker在集羣中的唯一表示，要求是正數。當該服務器的IP地址發生改變時，broker.id沒有變化，則不會影響consumers的消息情況
zookeeper.connect
zookeeper集羣的地址，可以是多個，多個之間用逗號分割
log.dirs
Kafka把所有的消息都保存在磁盤上，存放這些數據的目錄通過log.dirs指定。可以指定多個，充分利用磁盤的並行讀寫能力
num.recovery.threads.per.data.dir
每數據目錄用於日誌恢復啓動和關閉時的線程數量。因爲這些線程只是服務器啓動和關閉時會用到。所以完全可以設置大量的線程來達到並行操作的目的。注意，這個參數指的是每個日誌目錄的線程數，比如本參數設置爲8，而log.dirs設置爲了三個路徑，則總共會啓動24個線程。
auto.create.topics.enable
是否允許自動創建主題。如果設爲true，那麼produce，consume或者fetch metadata一個不存在的主題時，就會自動創建。缺省爲true。
主題配置（topic配置）
num.partitions
每個新建主題的分區個數。這個參數一般要評估，比如，每秒鐘要寫入和讀取1GB數據，如果現在每個消費者每秒鐘可以處理50MB的數據，那麼需要20個分區，這樣就可以讓20個消費者同時讀取這些分區，從而達到設計目標。
log.retention.hours
日誌保存時間，默認爲7天（168小時）。超過這個時間會清理數據。bytes和minutes無論哪個先達到都會觸發。與此類似還有log.retention.minutes和log.retention.ms，都設置的話，優先使用具有最小值的那個。
log.retention.bytes
topic每個分區的最大文件大小，一個topic的大小限制 = 分區數*log.retention.bytes。-1沒有大小限制。log.retention.bytes和log.retention.minutes任意一個達到要求，都會執行刪除。
log.segment.bytes
分區的日誌存放在某個目錄下諸多文件中，這些文件將分區的日誌切分成一段一段的，我們稱爲日誌片段。這個屬性就是每個文件的最大尺寸；當尺寸達到這個數值時，就會關閉當前文件，並創建新文件。被關閉的文件就開始等待過期。默認爲1G。
如果一個主題每天只接受100MB的消息，那麼根據默認設置，需要10天才能填滿一個文件。而且因爲日誌片段在關閉之前，消息是不會過期的，所以如果log.retention.hours保持默認值的話，那麼這個日誌片段需要17天才過期。因爲關閉日誌片段需要10天，等待過期又需要7天。
log.segment.ms
作用和log.segment.bytes類似，只不過判斷依據是時間。同樣的，兩個參數，以先到的爲準。這個參數默認是不開啓的。
message.max.bytes
表示一個服務器能夠接收處理的消息的最大字節數，注意這個值producer和consumer必須設置一致，且不要大於fetch.message.max.bytes屬性的值。該值默認是1000000字節，大概900KB~1MB。
3.硬件配置對Kafka性能的影響
磁盤吞吐量/磁盤容量
磁盤吞吐量會影響生產者的性能。因爲生產者的消息必須被提交到服務器保存，大多數的客戶端都會一直等待，直到至少有一個服務器確認消息已經成功提交爲止。也就是說，磁盤寫入速度越快，生成消息的延遲就越低。
磁盤容量的大小，則主要看需要保存的消息數量。如果每天收到1TB的數據，並保留7天，那麼磁盤就需要7TB的數據。
內存
Kafka本身並不需要太大內存，內存則主要是影響消費者性能。在大多數業務情況下，消費者消費的數據一般會從內存中獲取，這比在磁盤上讀取肯定要快的多。
網絡
網絡吞吐量決定了Kafka能夠處理的最大數據流量。
CPU
Kafka對cpu的要求不高，主要是用在對消息解壓和壓縮上。所以cpu的性能不是在使用Kafka的首要考慮因素。
4.爲何需要Kafka集羣
1.負載均衡：同一個主題的不同分區可以處在不同的broke中，生產者和消費者對當前主題進行操作可以落在不通的服務器上，減少服務器壓力
2.容災性。分區之間會發生複製功能，提供數據冗餘，當某一集羣掛掉後，會選出新的首領，再次把流量拉取到新的首領broke上即可。
3.性能提升，由於磁盤I/O或者內存等導致性能問題，可以通過添加機器來實現提升性能。
5.如何估算Kafka集羣中Broker的數量
需要多少磁盤空間保留數據，和每個broker上有多少空間可以用。比如，如果一個集羣有10TB的數據需要保留，而每個broker可以存儲2TB，那麼至少需要5個broker。如果啓用了數據複製，則還需要一倍的空間，那麼這個集羣需要10個broker。
6.Broker如何加入Kafka集羣
非常簡單，只需要兩個參數。第一，配置zookeeper.connect，第二，爲新增的broker設置一個集羣內的唯一性id。
畫一個自己對kafka的理解圖