您好,登錄后才能下訂單哦!
小編給大家分享一下Kafka通訊協(xié)議是怎么樣的,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
Kafka的Producer、Broker和Consumer之間采用的是一套自行設(shè)計的基于TCP層的協(xié)議。Kafka的這套協(xié)議完全是為了Kafka自身的業(yè)務(wù)需求而定制的,而非要實現(xiàn)一套類似于Protocol Buffer的通用協(xié)議。
定長數(shù)據(jù)類型:int8,int16,int32和int64,對應(yīng)到Java中就是byte, short, int和long。
變長數(shù)據(jù)類型:bytes和string。變長的數(shù)據(jù)類型由兩部分組成,分別是一個有符號整數(shù)N(表示內(nèi)容的長度)和N個字節(jié)的內(nèi)容。其中,N為-1表示內(nèi)容為null。bytes的長度由int32表示,string的長度由int16表示。
數(shù)組:數(shù)組由兩部分組成,分別是一個由int32類型的數(shù)字表示的數(shù)組長度N和N個元素。
Kafka中兩個角色之間通訊的基本單位是Request/Response,Request和Response的基本結(jié)構(gòu)如下:
RequestOrResponse => MessageSize (RequestMessage | ResponseMessage)
其中各字段的含義為:
名稱 | 類型 | 描述 |
---|---|---|
MessageSize | int32 | 表示RequestMessage或者ResponseMessage的長度 |
RequestMessage/ResponseMessage | - | 表示Request或者Response的內(nèi)容,在下面將會介紹其具體格式。 |
這個結(jié)構(gòu)定義了通訊雙方交換數(shù)據(jù)的基本結(jié)構(gòu)。通訊的過程可以簡單地表示為:客戶端打開與服務(wù)器端的Socket,然后往Socket寫入一個int32的數(shù)字表示這次發(fā)送的Request有多少字節(jié),然后繼續(xù)往Socket中寫入對應(yīng)字節(jié)數(shù)的數(shù)據(jù)。服務(wù)器端先讀出一個int32的整數(shù)從而獲取這次Request的大小,然后讀取對應(yīng)字節(jié)數(shù)的數(shù)據(jù)從而得到Request的具體內(nèi)容。服務(wù)器端處理了請求后,也用同樣的方式來發(fā)送響應(yīng)。
RequestMessage的結(jié)構(gòu)如下:
RequestMessage => ApiKey ApiVersion CorrelationId ClientId Request
名稱 | 類型 | 描述 |
---|---|---|
ApiKey | int16 | 表示這次請求的API編號 |
ApiVersion | int16 | 表示請求的API的版本,有了版本后就可以做到后向兼容 |
CorrelationId | int32 | 由客戶端指定的一個數(shù)字唯一標(biāo)示這次請求的id,服務(wù)器端在處理完請求后也會把同樣的CorrelationId寫到Response中,這樣客戶端就能把某個請求和響應(yīng)對應(yīng)起來了。 |
ClientId | string | 客戶端指定的用來描述客戶端的字符串,會被用來記錄日志和監(jiān)控,它唯一標(biāo)示一個客戶端。 |
Request | - | Request的具體內(nèi)容。 |
ResponseMessage的結(jié)構(gòu)如下:
ResponseMessage => CorrelationId Response
名稱 | 類型 | 描述 |
---|---|---|
CorrelationId | int32 | 對應(yīng)Request的CorrelationId。 |
Response | - | 對應(yīng)Request的Response,不同的Request的Response的字段是不一樣的。 |
Kafka是一個分布式消息系統(tǒng),Producer生產(chǎn)消息并推送(Push)給Broker,然后Consumer再從Broker那里取走(Pull)消息。Producer生產(chǎn)的消息就是由Message來表示的,對用戶來講,它就是鍵-值對,來看看它的結(jié)構(gòu)。
Message => Crc MagicByte Attributes Key Value
名稱 | 類型 | 描述 |
---|---|---|
CRC | int32 | 表示這條消息(不包括CRC字段本身)的校驗碼 |
MagicByte | int8 | 表示消息格式的版本,用來做后向兼容,目前值為0 |
Attributes | int8 | 表示這條消息的元數(shù)據(jù),目前最低兩位用來表示壓縮格式 |
Key | bytes | 表示這條消息的Key,可以為null |
Value | bytes | 表示這條消息的Value。Kafka支持消息嵌套,也就是把一條消息作為Value放到另外一條消息里面。 |
MessageSet用來組合多條Message,它在每條Message的基礎(chǔ)上加上了Offset和MessageSize,其結(jié)構(gòu)是:
MessageSet => [Offset MessageSize Message]
它的含義是MessageSet是個數(shù)組,數(shù)組的每個元素由三部分組成,分別是Offset,MessageSize和Message,它們的含義分別是:
名稱 | 類型 | 描述 |
---|---|---|
Offset | int64 | 它用來作為log中的序列號,Producer在生產(chǎn)消息的時候還不知道具體的值是什么,可以隨便填個數(shù)字進去 |
MessageSize | int32 | 表示這條Message的大小 |
Message | - | 表示這條Message的具體內(nèi)容,其格式見上一小節(jié)。 |
Kafka支持下面幾種壓縮方式,
壓縮方式 | 編碼 |
---|---|
不壓縮 | 0 |
Gzip | 1 |
Snappy | 2 |
LZ4 | 3 |
其中編碼就是Message的Attribute的最低兩位的值。
因為單條消息中重復(fù)內(nèi)容可能不多,所以通常把多條消息放在一起組成MessageSet,然后再把MessageSet放到一條Message里面去,從而提高壓縮比率。
Request/Response是通訊層的結(jié)構(gòu),和網(wǎng)絡(luò)的7層模型對比的話,它類似于TCP層。
Message/MessageSet定義的是業(yè)務(wù)層的結(jié)構(gòu),類似于網(wǎng)絡(luò)7層模型中的HTTP層。Message/MessageSet只是Request/Response的payload中的一種數(shù)據(jù)結(jié)構(gòu)。
以上是“Kafka通訊協(xié)議是怎么樣的”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。