Kafka教程(一)Kafka入門教程
1 Kafka入門教程
1.1 消息隊列(Message Queue)
Message Queue消息傳送系統提供傳送服務。消息傳送依賴於大量支持組件,這些組件負責處理連接服務、消息的路由和傳送、持久性、安全性以及日誌記錄。消息服務器可以使用一個或多個代理實例。
JMS(Java Messaging Service)是Java平臺上有關面向消息中間件(MOM)的技術規範,它便於消息系統中的Java應用程序進行消息交換,並且通過提供標準的產生、發送、接收消息的接口簡化企業應用的開發,翻譯爲Java消息服務。
1.2 MQ消息模型
KafkaMQ消息模型圖1-1
1.3 MQ消息隊列分類
消息隊列分類:點對點和發佈/訂閱兩種:
1、點對點:
消息生產者生產消息發送到queue中,然後消息消費者從queue中取出並且消費消息。
消息被消費以後,queue中不再有存儲,所以消息消費者不可能消費到已經被消費的消息。Queue支持存在多個消費者,但是對一個消息而言,只會有一個消費者可以消費。
2、發佈/訂閱:
消息生產者(發佈)將消息發佈到topic中,同時有多個消息消費者(訂閱)消費該消息。和點對點方式不同,發佈到topic的消息會被所有訂閱者消費。
1.4 MQ消息隊列對比
1、RabbitMQ:支持的協議多,非常重量級消息隊列,對路由(Routing),負載均衡(Loadbalance)或者數據持久化都有很好的支持。
2、ZeroMQ:號稱最快的消息隊列系統,尤其針對大吞吐量的需求場景,擅長的高級/複雜的隊列,但是技術也複雜,並且只提供非持久性的隊列。
3、ActiveMQ:Apache下的一個子項,類似ZeroMQ,能夠以代理人和點對點的技術實現隊列。
4、Redis:是一個key-Value的NOSql數據庫,但也支持MQ功能,數據量較小,性能優於RabbitMQ,數據超過10K就慢的無法忍受。
1.5 Kafka簡介
Kafka是分佈式發佈-訂閱消息系統,它最初由 LinkedIn 公司開發,使用 Scala語言編寫,之後成爲 Apache 項目的一部分。在Kafka集羣中,沒有“中心主節點”的概念,集羣中所有的服務器都是對等的,因此,可以在不做任何配置的更改的情況下實現服務器的的添加與刪除,同樣的消息的生產者和消費者也能夠做到隨意重啓和機器的上下線。
Kafka消息系統生產者和消費者部署關係圖1-2
Kafka消息系統架構圖1-3
1.6 Kafka術語介紹
1、消息生產者:即:Producer,是消息的產生的源頭,負責生成消息併發送到Kafka
服務器上。
2、消息消費者:即:Consumer,是消息的使用方,負責消費Kafka服務器上的消息。
3、主題:即:Topic,由用戶定義並配置在Kafka服務器,用於建立生產者和消息者之間的訂閱關係:生產者發送消息到指定的Topic下,消息者從這個Topic下消費消息。
4、消息分區:即:Partition,一個Topic下面會分爲很多分區,例如:“kafka-test”這個Topic下可以分爲6個分區,分別由兩臺服務器提供,那麼通常可以配置爲讓每臺服務器提供3個分區,假如服務器ID分別爲0、1,則所有的分區爲0-0、0-1、0-2和1-0、1-1、1-2。Topic物理上的分組,一個 topic可以分爲多個 partition,每個 partition 是一個有序的隊列。partition中的每條消息都會被分配一個有序的 id(offset)。
5、Broker:即Kafka的服務器,用戶存儲消息,Kafa集羣中的一臺或多臺服務器統稱爲 broker。
6、消費者分組:Group,用於歸組同類消費者,在Kafka中,多個消費者可以共同消息一個Topic下的消息,每個消費者消費其中的部分消息,這些消費者就組成了一個分組,擁有同一個分組名稱,通常也被稱爲消費者集羣。
7、Offset:消息存儲在Kafka的Broker上,消費者拉取消息數據的過程中需要知道消息在文件中的偏移量,這個偏移量就是所謂的Offset。
1.7 Kafka中Broker
1、Broker:即Kafka的服務器,用戶存儲消息,Kafa集羣中的一臺或多臺服務器統稱爲 broker。
2、Message在Broker中通Log追加的方式進行持久化存儲。並進行分區(patitions)。
3、爲了減少磁盤寫入的次數,broker會將消息暫時buffer起來,當消息的個數(或尺寸)達到一定閥值時,再flush到磁盤,這樣減少了磁盤IO調用的次數。
4、Broker沒有副本機制,一旦broker宕機,該broker的消息將都不可用。Message消息是有多份的。
5、Broker不保存訂閱者的狀態,由訂閱者自己保存。
6、無狀態導致消息的刪除成爲難題(可能刪除的消息正在被訂閱),kafka採用基於時間的SLA(服務水平保證),消息保存一定時間(通常爲7天)後會被刪除。
7、消息訂閱者可以rewind back到任意位置重新進行消費,當訂閱者故障時,可以選擇最小的offset(id)進行重新讀取消費消息。
1.8 Kafka的Message組成
1、Message消息:是通信的基本單位,每個 producer 可以向一個 topic(主題)發佈一些消息。
2、Kafka中的Message是以topic爲基本單位組織的,不同的topic之間是相互獨立的。每個topic又可以分成幾個不同的partition(每個topic有幾個partition是在創建topic時指定的),每個partition存儲一部分Message。
3、partition中的每條Message包含了以下三個屬性:
offset 即:消息唯一標識:對應類型:long
MessageSize 對應類型:int32
data 是message的具體內容。
1.9 Kafka的Partitions分區
1、Kafka基於文件存儲.通過分區,可以將日誌內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每個partiton都會被當前server(kafka實例)保存。
2、可以將一個topic切分多任意多個partitions,來消息保存/消費的效率。
3、越多的partitions意味着可以容納更多的consumer,有效提升併發消費的能力。
1.10 Kafka的Consumers
1、消息和數據消費者,訂閱 topics並處理其發佈的消息的過程叫做 consumers。
2、在 kafka中,我們可以認爲一個group是一個“訂閱者”,一個Topic中的每個partions,只會被一個“訂閱者”中的一個consumer消費,不過一個 consumer可以消費多個partitions中的消息(消費者數據小於Partions的數量時)。注意:kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,否則將意味着某些consumer將無法得到消息。
3、一個partition中的消息只會被group中的一個consumer消息。每個group中consumer消息消費互相獨立。
1.11 Kafka的持久化
1、一個Topic可以認爲是一類消息,每個topic將被分成多partition(區),每個partition在存儲層面是append log文件。任何發佈到此partition的消息都會被直接追加到log文件的尾部,每條消息在文件中的位置稱爲offset(偏移量),partition是以文件的形式存儲在文件系統中。
2、Logs文件根據broker中的配置要求,保留一定時間後刪除來釋放磁盤空間。
Kafka消息分區Partition圖1-4
Partition:
Topic物理上的分組,一個 topic可以分爲多個 partition,每個 partition 是一個有序的隊列。partition中的每條消息都會被分配一個有序的 id(offset)。
3、爲數據文件建索引:稀疏存儲,每隔一定字節的數據建立一條索引。下圖爲一個partition的索引示意圖:
Kafka消息分區Partition索引圖1-5
1.12 Kafka的分佈式實現:
Kafka分佈式關係圖1-6
Kafka生產環境關係圖1-7
1.13 Kafka的通訊協議:
1、Kafka的Producer、Broker和Consumer之間採用的是一套自行設計基於TCP層的協議,根據業務需求定製,而非實現一套類似ProtocolBuffer的通用協議。
2、基本數據類型:(Kafka是基於Scala語言實現的,類型也是Scala中的數據類型)
定長數據類型:int8,int16,int32和int64,對應到Java中就是byte, short, int和long。
變長數據類型:bytes和string。變長的數據類型由兩部分組成,分別是一個有符號整數N(表示內容的長度)和N個字節的內容。其中,N爲-1表示內容爲null。bytes的長度由int32表示,string的長度由int16表示。
數組:數組由兩部分組成,分別是一個由int32類型的數字表示的數組長度N和N個元素。
3、Kafka通訊的基本單位是Request/Response。
4、基本結構:
RequestOrResponse => MessageSize(RequestMessage | ResponseMessage)
名稱 |
類型 |
描術 |
MessageSize |
int32 |
表示RequestMessage或者ResponseMessage的長度
|
RequestMessage ResponseMessage |
— |
|
5、通訊過程:
客戶端打開與服務器端的Socket
往Socket寫入一個int32的數字(數字表示這次發送的Request有多少字節)
服務器端先讀出一個int32的整數從而獲取這次Request的大小
然後讀取對應字節數的數據從而得到Request的具體內容
服務器端處理了請求後,也用同樣的方式來發送響應。
6、RequestMessage結構:
RequestMessage => ApiKey ApiVersionCorrelationId ClientId Request
名稱 |
類型 |
描術 |
ApiKey |
int16 |
表示這次請求的API編號 |
ApiVersion |
int16 |
表示請求的API的版本,有了版本後就可以做到後向兼容 |
CorrelationId |
int32 |
由客戶端指定的一個數字唯一標示這次請求的id,服務器端在處理完請求後也會把同樣的CorrelationId寫到Response中,這樣客戶端就能把某個請求和響應對應起來了。 |
ClientId |
string |
客戶端指定的用來描述客戶端的字符串,會被用來記錄日誌和監控,它唯一標示一個客戶端。 |
Request |
— |
Request的具體內容。 |
7、ResponseMessage結構:
ResponseMessage => CorrelationId Response
名稱 |
類型 |
描術 |
CorrelationId |
int32 |
對應Request的CorrelationId。 |
Response |
— |
對應Request的Response,不同的Request的Response的字段是不一樣的。 |
Kafka採用是經典的Reactor(同步IO)模式,也就是1個Acceptor響應客戶端的連接請求,N個Processor來讀取數據,這種模式可以構建出高性能的服務器。
8、Message結構:
Message:Producer生產的消息,鍵-值對
Message => Crc MagicByte Attributes KeyValue
名稱 |
類型 |
描術 |
CRC |
int32 |
表示這條消息(不包括CRC字段本身)的校驗碼。 |
MagicByte |
int8 |
表示消息格式的版本,用來做後向兼容,目前值爲0。 |
Attributes |
int8 |
表示這條消息的元數據,目前最低兩位用來表示壓縮格式。 |
Key |
bytes |
表示這條消息的Key,可以爲null。 |
Value |
bytes |
表示這條消息的Value。Kafka支持消息嵌套,也就是把一條消息作爲Value放到另外一條消息裏面。 |
9、MessageSet結構:
MessageSet:用來組合多條Message,它在每條Message的基礎上加上了Offset和MessageSize
MessageSet => [Offset MessageSize Message]
名稱 |
類型 |
描術 |
Offset |
int64 |
它用來作爲log中的序列號,Producer在生產消息的時候還不知道具體的值是什麼,可以隨便填個數字進去。 |
MessageSize |
int32 |
表示這條Message的大小。 |
Message |
- |
表示這條Message的具體內容,其格式見上一小節。 |
10、 Request/Respone和Message/MessageSet的關係:
Request/Response是通訊層的結構,和網絡的7層模型對比的話,它類似於TCP層。
Message/MessageSet定義的是業務層的結構,類似於網絡7層模型中的HTTP層。Message/MessageSet只是Request/Response的payload中的一種數據結構。
備註:Kafka的通訊協議中不含Schema,格式也比較簡單,這樣設計的好處是協議自身的Overhead小,再加上把多條Message放在一起做壓縮,提高壓縮比率,從而在網絡上傳輸的數據量會少一些。
1.14 數據傳輸的事務定義:
1、at most once:最多一次,這個和JMS中"非持久化"消息類似.發送一次,無論成敗,將不會重發。
at most once:消費者fetch消息,然後保存offset,然後處理消息;當client保存offset之後,但是在消息處理過程中出現了異常,導致部分消息未能繼續處理.那麼此後"未處理"的消息將不能被fetch到,這就是"atmost once"。
2、at least once:消息至少發送一次,如果消息未能接受成功,可能會重發,直到接收成功。
at least once:消費者fetch消息,然後處理消息,然後保存offset.如果消息處理成功之後,但是在保存offset階段zookeeper異常導致保存操作未能執行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的消息,這就是"atleast once",原因offset沒有及時的提交給zookeeper,zookeeper恢復正常還是之前offset狀態。
3、exactly once:消息只會發送一次。
exactly once: kafka中並沒有嚴格的去實現(基於2階段提交,事務),我們認爲這種策略在kafka中是沒有必要的。
注:通常情況下"at-least-once"是我們首選。(相比at most once而言,重複接收數據總比丟失數據要好)。
1.15 學習Kafka推薦書籍:
1. 《Apache Kafka》
2. 《從Paxos到Zookeeper分佈式一