1、基本概念
需要了解producer,consumer,groupId,broker,topic,partition,segment的概念，如下圖。
2、版本名
kafka_2.10-0.8.2.jar，2.10是指Scala版本，0.8.2是指kafka版本。
3、核心功能
Producer API允許程序發布數據流到一個到多個Kafka topic。
Consumer API允許程序訂閱一個到多個topic，並且進行消費。
Streams API允許程序作為一個數據流處理，將一個或多個topic中輸入的數據進行消費，並生產數據流到一個或多個topics中。
Connector API，可以通過Connector管理Kafka和另一個系統之間的數據復制，比如去捕獲關系型數據庫中的任意改變到一個表中。
4、topic介紹
topic（不同的業務數據，分流到不同的topic進行處理）
\\
\\
topic是基於zk建立的，實 \\ 際上同一topic下的partition是按如下分布在各個服務器上的(可以設置replicas的個數，此圖partition黑色為leader，紅色為 \\ 副本folower)。
\ \\ /
\||/
kafka對與zookeeper是強依賴的，是以zookeeper作為基礎的，即使不做集群，也需要zk的支持。以下是kafka中必須要填寫的配置文件，id為在zk中注冊的brokerid，后者為要注冊到的zookeeper的host和port。
broker.id=0
zookeeper.connect=localhost:2181
zk說白了，就是一個節點服務系統，至於用這個節點做什么，做單活、開關鎖還是做檢測服務器存活狀態，都是業務代碼根據這個節點做的一些邏輯處理。以下是kafka默認在zk中的節點層級結構：
5、partition介紹
partion可以看作一個有序的隊列，里面的數據是儲存在硬盤中的，追加式的。partition的作用就是提供分布式的擴展，一個topic可以有許多partions，多個partition可以並行處理數據，所以可以處理相當量的數據。只有partition的leader才會進行讀寫操作，folower僅進行復制，客戶端是感知不到的。下圖把kafka集群看成一個kakfa服務，僅顯示leader。
1）offset概念
每一條數據都有一個offset，是每一條數據在該partition中的唯一標識。各個consumer控制和設置其在該partition下消費到offset位置，這樣下次可以以該offset位置開始進行消費。
各個consumer的offset位置默認是在某一個broker當中的topic中保存的（為防止該broker宕掉無法獲取offset信息，可以配置在每個broker中都進行保存，配置文件中配置）
offsets.topic.replication.factor=3 transaction.state.log.replication.factor=3 transaction.state.log.min.isr=3
2）replicas的同步時機。
假如有N個replicas，其中一個replica為leader，其他都為follower，leader處理partition的所有讀寫請求，於此同時，follower會被動定期的去復制leader上的數據。
3）ISR介紹
leader會追蹤和維護ISR中所有follower的滯后狀態。如果滯后太多（數量滯后和時間滯后兩個維度，replica.lag.time.max.ms和replica.lag.max.message可配置），leader會把該replica從ISR中移除。被移除ISR的replica一直在追趕leader。如下圖，leader寫入數據后並不會commit，只有ISR列表中的所有folower同步之后才會commit，把滯后的follower移除ISR主要是避免寫消息延遲。設置ISR主要是為了broker宕掉之后，重新選舉partition的leader從ISR列表中選擇。
滯后情況：新增副本，GC掛起，follower失效，I/O瓶頸。
6、producer介紹
send(String topic, Integer partition, Long timestamp, K key, V data)
producer在發送消息的時候，必須指定topic和data,可以選擇指定partion、key、timestamp,其中時間戳有兩種方式，CreateTime和LogAppendTime，前者是客戶端設置時間，后者是broker在消息寫入log時設置的時間。如果為null，用的是System.currentTimeMillis()。如果同時不指定partition和key，那么就用round-bin決定發送到哪個partition。
客戶端會定時的取Broker的topic、partition、replicas等元數據信息，producer持有kafka節點的metadata信息，通過該信息創建ProducerPool，每次發送信息會根據要發送哪個Partition，來選擇相應的Producer實例，Rpc連接。
7、consumer介紹
以下針對springBoot集成的kafka
@KafkaListener(topics = {"cache-music-user"},groupId="zwhUser",containerFactory = "batchAbleFactory")
public void consumeBatch(List<ConsumerRecord<String,String>> recordList, Acknowledgment acknowledgment) throws InterruptedException {
...
方法體
...
}
consumer如何知道自己應該拉取哪一個partition。cordinator（某一個Kafka的broker）在分配consumer的時候，會選舉consumer leader，后者分配每一個consumer要連接的broker,topic,partition，然后上報cordinator。然后consumer會根據自己被分配的partion去拉取數據。
批量讀取和單數據讀取，ack機制。
如果poll()時間超時，那么broker會認為consumer掛掉了，會踢掉該consumer。cordinator重新分配consumer。有時超時會拋異常，不過也會重新分配consumer。
consumer的groupId機制。對於一個groupId中的consumer來說，一個partition只能由一個consumer來消費。即不可能多個consumer消費1個partition。如下：
consumer可以在不同的機器中。
三、延伸
1、kafka重新選舉
KafkaController的作用。Kafka集群中多個broker，有一個會被選舉為controller leader，負責管理整個集群中分區和副本的狀態，比如partition的leader 副本故障，由controller 負責為該partition重新選舉新的leader 副本；當檢測到ISR列表發生變化，有controller通知集群中所有broker更新其MetadataCache信息；或者增加某個topic分區的時候也會由controller管理分區的重新分配工作
KafkaController創建節點的方式去選舉，作為leader，任何follower掛了，zk會感知到並通過Controller注冊的Wather去通知Controller去重新選舉。而leader掛了，zk會感知到，會通過Wather機制通知每一個broker去競爭Master。而ReplicaManager每個broker都有，是接受Contrloller的請求，對本服務上的partition進行管理的。
2、效率高的原因
因為kafka的數據都是存儲在硬盤中，甚至有的公司將kafka其作為數據庫使用，既然數據是基於硬盤的，那么為何kafka還是能夠擁有如此高的吞吐量呢？
1）硬盤的索引功能。二分查找法。
分區：找到響應的分區
分段：根據文件segment的命名可以確認要查找的offset或timestamp在哪個文件中。
稀疏索引：快速確定要找的offset在哪個內存地址的附近。
2）I/O優化
普通程序I/O需要把Disk中的信息復制到系統環境內存（步驟1），再復制到kafka應用環境內存（步驟2），然后步驟3，步驟4到Socket通過網絡發出，重復復制文本，I/O消耗大。
kafka則不一樣：
3、kafka和rabbitMq的對比。
kafka是一種高吞吐量的分布式發布訂閱消息系統。和rabbitMq各占半臂江山。以下是對比：
性能來說，kafka的吞吐量較大。kafka易於向外擴展，所有的producer、broker、consumer無需停機都可以即刻擴展機器。信息將全部的信息持久化到硬盤上，生產和消費互不影響，很靈活。功能來說，kafka適用於日志，事實上kafka本身就是LinkIn公司開發用於日志系統的，所以其文件叫做log。用戶跟蹤管道，對用戶網頁行為的記錄跟蹤，用於離線數據分析或者做報表。大數據分析。
轉自https://blog.csdn.net/dshf_1/article/details/82467558