kafka核心概念和角色

1.概述

kafka裏面的消息是有topic來組織的，簡單的我們可以想象爲一個隊列

• 一個topic就是一個消息隊列，然後它把每個topic又分爲很多個partition

  • 這個是爲了做並行的，更加方便擴展，而且提高了吞吐量
  • 在每個partition內部消息強有序，相當於有序的隊列，其中每個消息都有個序號offset，比如0到12，從前面讀往後面寫。

• 一個partition對應一個broker，一個broker可以管理多個partition

  比如說，topic有6個partition，有兩個broker，那每個broker就管3個partition。

• partition可以想象爲一個文件，當數據發過來的時候它就往這個partition上面追加就行，消息不經過內存緩衝，直接寫入文件

  kafka和很多消息系統不一樣，很多消息系統是消費完了就把它刪掉，而kafka是根據時間策略刪除，而不是消費完就刪除，在kafka裏面沒有一個消費完這麼個概念，只有過期這樣一個概念。

• producer自己決定往哪個partition裏面去寫，這裏有一些的策略，譬如hash。

  consumer自己維護消費到哪個offset，每個consumer都有對應的組

  • 組內：是queue消費模型，各個consumer消費不同的partition，因此一個消息在group內只消費一次
  • 組間：是發佈/訂閱消費模型，各個組各自獨立消費，互不影響，因此一個消息只被每個組消費一次

1. Topic可以類比爲數據庫中的庫
2. partition可以類比爲數據庫中的表
3. 一個topic就是一個消息隊列，然後它把每個topic又分爲很多個partition
4. 一個topic可以有多個消費者組
5. 同一個消費者組內的消費者在消費同一個topic時，這個topic中相同的數據只能被消費一次，即每個partion只會把消息發給該消費者組中的一個消費者
6. 不同的消費者組消費同一個topic互不影響
7. 一臺kafka服務器節點就是一個broker。一個集羣由多個broker組成。一個broker可以容納多個topic。

2.Producer

消息生產者，就是向kafka broker發消息的客戶端。生產者負責將記錄分配到topic的指定 partition（分區）中

生產者會決定發送到哪個Partition，有兩種發送的機制：

1. 輪詢(Round robin)

   先隨機到某一個partition上一直持續的寫，大概寫個十分鐘，再隨機到一個partition再去寫，所以一般建議生產消息都按照建個key來按照hash去分，還可以自定義按照key怎麼去分

2. key的hash

   如果key爲null，就是輪詢，否則就是按照key的hash

3.Consumer

消息消費者，向kafka broker取消息的客戶端。每個消費者都要維護自己讀取數據的offset。

• 每個consumer都有自己的消費者組group
• 同一個消費者組內的消費者在消費同一個topic時，這個topic中相同的數據只能被消費一次
• 不同的消費者組消費同一個topic互不影響
• 低版本0.9之前將offset保存在Zookeeper中，0.9及之後保存在Kafka的“__consumer_offsets”主題中。

4.Consumer Group

每個消費者都會使用一個消費組名稱來進行標識。同一個組中的不同的消費者實例，可以分佈在多個進程或多個機器上。

消費者組，由多個consumer組成。

• 一個topic可以有多個消費者組。topic的消息會複製（不是真的複製，是概念上的）到所有的CG，但每個partion只會把消息發給該CG中的一個consumer。

• 消費者組內每個消費者負責消費不同分區的數據，一個分區只能由一個消費者消費；

• 消費者組之間互不影響。

• 所有的消費者都屬於某個消費者組，即消費者組是邏輯上的一個訂閱者。

• 如果所有的消費者實例在同一消費組中，消息記錄會負載平衡到每一個消費者實例（單播）。即每個消費者可以同時讀取一個topic的不同分區！

消費者組是kafka用來**實現一個topic消息的廣播（發給所有的消費者）和單播（發給任意一個消費者）**的手段。

• 如果需要實現廣播，只要每個消費者有一個獨立的消費者組就可以了。

• 如果需要實現單播，只要所有的消費者在同一個消費者組。用消費者組還可以將消費者進行自由的分組而不需要多次發送消息到不同的topic。

5.Broker

kafka集羣的server，一臺kafka服務器節點就是一個broker，負責處理消息讀、寫請求，存儲消息，在kafka cluster這一層這裏，其實裏面是有很多個broker

• 一個集羣由多個broker組成。一個broker可以容納多個topic。
• broker是組成kafka集羣的節點，broker之間沒有主從關係，各個broker之間的協調依賴於zookeeper，如數據在哪個節點上之類的

Kafka集羣中有一個broker會被選舉爲Controller，負責管理集羣broker的上下線，所有topic的分區副本分配和leader選舉等工作。

Controller的管理工作都是依賴於Zookeeper的。

6.Topic

Topic 就是數據主題，kafka建議根據業務系統將不同的數據存放在不同的topic中。如：日誌的消息可以放在一個topic，金額的消息可以放在一個topic，不同類別的消息放在不同的topic內，這次取消息更方便

• Kafka中的Topics總是多訂閱者模式，一個topic可以擁有一個或者多個消費者來訂閱它的數據
• 一個大的Topic可以分佈式存儲在多個kafka broker中
• Topic可以類比爲數據庫中的庫

一個topic就是一個消息隊列，然後它把每個topic又分爲很多個partition

• 這個是爲了做並行的，更加方便擴展，而且提高了吞吐量
• 在每個partition內部消息強有序，相當於有序的隊列，其中每個消息都有個序號offset，比如0到12，從前面讀往後面寫。

7.Partition

1. 一個topic可以分爲多個partition，通過分區的設計，topic可以不斷進行擴展。即一個Topic的多個分區分佈式存儲在多個broker(服務器)上。此外通過分區還可以讓一個topic被多個consumer進行消費。以達到並行處理。分區可以類比爲數據庫中的表。

2. partition內部有序，但一個topic的整體（多個partition間）不一定有序

   kafka只保證按一個partition中的順序將消息發給consumer，partition中的每條消息都會被分配一個有序的id（offset），每個partition內部消息是一個強有序的隊列，但不保證一個topic的整體（多個partition間）的順序。

3. 一個partition對應一個broker，一個broker可以管理多個partition

   比如說，topic有6個partition，有兩個broker，那每個broker就管3個partition。

4. partition可以很簡單想象爲一個文件，partition對應磁盤上的目錄，當數據發過來的時候它就往這個partition上面追加，消息不經過內存緩衝，直接寫入文件

   kafka爲每個主題維護了分佈式的分區(partition)日誌文件，每個partition在kafka存儲層面是append log。任何發佈到此partition的消息都會被追加到log文件的尾部，在分區中的每條消息都會按照時間順序分配到一個單調遞增的順序編號，也就是我們的offset,offset是一個long型的數字，我們通過這個offset可以確定一條在該partition下的唯一消息。在partition下面是保證了有序性，但是在topic下面沒有保證有序性。

5. 每個partition都會有副本，可以在創建topic時來指定有幾個副本

8.Offset

kafka的存儲文件都是按照offset.kafka來命名，用offset做名字的好處是方便查找。例如你想找位於2049的位置，只要找到2048.kafka的文件即可。當然the first offset就是00000000000.kafka

數據會按照時間順序被不斷第追加到分區的一個結構化的commit log中！每個分區中存儲的記錄都是有序的，且順序不可變！

這個順序是通過一個稱之爲offset的id來唯一標識！因此也可以認爲offset是有序且不可變的！

在每一個消費者端，會唯一保存的元數據是offset（偏移量）,即消費在log中的位置，偏移量由消費者所控制。通常在讀取記錄後，消費者會以線性的方式增加偏移量，但是實際上，由於這個位置由消費者控制，所以消費者可以採用任何順序來消費記錄。例如，一個消費者可以重置到一箇舊的偏移量，從而重新處理過去的數據；也可以跳過最近的記錄，從"現在"開始消費。

這些細節說明Kafka 消費者是非常廉價的—消費者的增加和減少，對集羣或者其他消費者沒有多大的影響。比如，你可以使用命令行工具，對一些topic內容執行 tail操作，並不會影響已存在的消費者消費數據。

圖1 Topic拓撲結構

圖2 數據流

9.持久化

Kafka 集羣保留所有發佈的記錄—無論他們是否已被消費—並通過一個可配置的參數——保留期限來控制。舉個例子， 如果保留策略設置爲2天，一條記錄發佈後兩天內，可以隨時被消費，兩天過後這條記錄會被清除並釋放磁盤空間。

Kafka的性能和數據大小無關，所以長時間存儲數據沒有什麼問題。

10.Replica副本機制

副本，爲保證集羣中的某個節點發生故障時，該節點上的partition數據不丟失，且kafka仍然能夠繼續工作，kafka提供了副本機制，一個topic的每個分區都有若干個副本，一個leader和若干個follower。

日誌的分區partition （分佈）在Kafka集羣的服務器上。每個服務器在處理數據和請求時，共享這些分區。每一個分區都會在已配置的服務器上進行備份，確保容錯性。

每個分區都有一臺 server 作爲 “leader”，零臺或者多臺server作爲 follwers 。leader server 處理一切對 partition （分區）的讀寫請求，而follwers只需被動的同步leader上的數據。當leader宕機了，followers 中的一臺服務器會自動成爲新的 leader。通過這種機制，既可以保證數據有多個副本，也實現了一個高可用的機制！

同一個partition可能會有多個replication（對應 server.properties 配置中的 default.replication.factor=N）。沒有replication的情況下，一旦broker 宕機，其上所有 partition 的數據都不可被消費，同時producer也不能再將數據存於其上的patition。引入replication之後，同一個partition可能會有多個replication，而這時需要在這些replication之間選出一個leader，producer和consumer只與這個leader交互，其它replication作爲follower從leader 中複製數據。

基於安全考慮，每個分區的Leader和follower一般會錯在在不同的broker!

leader

每個分區多個副本的“主”，生產者發送數據的對象，以及消費者消費數據的對象都是leader。

follower

每個分區多個副本中的“從”，實時從leader中同步數據，保持和leader數據的同步。leader發生故障時，某個follower會成爲新的follower。

11.zookeeper

元數據信息存在zookeeper中，包括：broker，topic，partition的元數據消息(存儲消費偏移量，topic話題信息，partition信息)。kafka0.8之前還可以存儲消費者offset

Kafka集羣中有一個broker會被選舉爲Controller，負責管理集羣broker的上下線，所有topic的分區副本分配和leader選舉等工作。

Controller的管理工作都是依賴於Zookeeper的。