通過(guò)上篇文章的學(xué)習(xí)钳踊，我們對(duì)Kafka時(shí)間流平臺(tái)有了初步的認(rèn)識(shí)资溃，并且也了解了組成Kafka的核心組件泳梆。整個(gè)Kafka的最核心部分其實(shí)就是我們所有的服務(wù)器端鳖悠，也叫Broker，Broker在整個(gè)Kafka平臺(tái)上承擔(dān)了服務(wù)器端和數(shù)據(jù)存儲(chǔ)層的職責(zé)优妙。
Broker作為數(shù)據(jù)的存儲(chǔ)層乘综，需要負(fù)責(zé)數(shù)據(jù)管理，過(guò)期數(shù)據(jù)管理套硼，數(shù)據(jù)復(fù)制來(lái)保證可靠性等任務(wù)卡辰，過(guò)期數(shù)據(jù)管理決定了我們的消息數(shù)據(jù)會(huì)被保存多長(zhǎng)的時(shí)間，而數(shù)據(jù)復(fù)制機(jī)制會(huì)將數(shù)據(jù)在多個(gè)節(jié)點(diǎn)上進(jìn)行備份邪意，當(dāng)某臺(tái)Broker由于軟硬件故障出現(xiàn)問(wèn)題九妈，數(shù)據(jù)不會(huì)因此而丟失。
除了管理數(shù)據(jù)的職責(zé)雾鬼，Broker也負(fù)責(zé)處理從生產(chǎn)者客戶端來(lái)的消息發(fā)送請(qǐng)求處理萌朱，下圖生產(chǎn)者客戶端和Broker進(jìn)行數(shù)據(jù)交互的示意圖：
如上圖所示，生產(chǎn)者客戶端發(fā)送請(qǐng)求給Broker策菜，Broker收到請(qǐng)求后晶疼，將消息保存到自己的文件系統(tǒng)，然后發(fā)送響應(yīng)給客戶端做入，這是最基本的交互方式冒晰。但是基于筆者最近在多個(gè)項(xiàng)目上代碼評(píng)審的結(jié)果看同衣，消息發(fā)送端代碼寫的不規(guī)范時(shí)有發(fā)生竟块。以下是筆者最近在代碼評(píng)審過(guò)程中總結(jié)的MQ代碼編寫規(guī)范，大家可以參考一下：
1耐齐，在生產(chǎn)者客戶端要主動(dòng)捕捉消息發(fā)送的異常浪秘，特別是采用異步發(fā)送的接口的生產(chǎn)者代碼蒋情。而在消費(fèi)者客戶端，首先必須確保關(guān)閉自動(dòng)點(diǎn)位提交功能耸携。
2棵癣，大部分消息隊(duì)列出現(xiàn)消息丟失的場(chǎng)景都發(fā)生在消費(fèi)者端，因此我們必須遵守：在編寫消費(fèi)者端業(yè)務(wù)處理代碼的時(shí)候夺衍，請(qǐng)確保先進(jìn)行業(yè)務(wù)邏輯處理狈谊，處理成功后才提交點(diǎn)位，防止提前提交了點(diǎn)位沟沙，但是后續(xù)消費(fèi)處理出現(xiàn)問(wèn)題河劝，消息消費(fèi)丟失。
3矛紫，消費(fèi)者端的消息處理代碼必須簡(jiǎn)潔赎瞎，簡(jiǎn)單和高效。并且必須做到冪等颊咬，當(dāng)出現(xiàn)重復(fù)消息的時(shí)候务甥，不至于造成業(yè)務(wù)異常。
4喳篇，消費(fèi)者的數(shù)量不要超過(guò)分區(qū)的數(shù)量敞临，造成資源浪費(fèi)。
5麸澜，消息隊(duì)列在主題層面并不能保證消息的有序哟绊，因此如果我們需要保證有序消費(fèi)，要給需要有序消費(fèi)的消息設(shè)置相同的key痰憎，這樣分區(qū)分配攔截器就可以將持有相同key的消息發(fā)送到相同的分區(qū)上票髓。我們也應(yīng)該從業(yè)務(wù)上給每個(gè)數(shù)據(jù)設(shè)置版本號(hào)，這樣當(dāng)同一個(gè)數(shù)據(jù)多個(gè)版本消息亂序被消費(fèi)的時(shí)候铣耘，確保數(shù)據(jù)不會(huì)出現(xiàn)老版本更新新版本洽沟。
6，采用MQ來(lái)進(jìn)行系統(tǒng)數(shù)據(jù)交互要考慮一致性的問(wèn)題蜗细，因?yàn)檫@種模式是數(shù)據(jù)最終一致方案裆操，不是強(qiáng)一致。如果用戶對(duì)數(shù)據(jù)一致性要求極高炉媒，建議采用事務(wù)的方式踪区。
7，基于MQ的核心系統(tǒng)方案中吊骤，要做好業(yè)務(wù)監(jiān)控缎岗，以及以人工處理作為兜底方案。因此需要引入統(tǒng)一日志收集和監(jiān)控告警白粉，全鏈路監(jiān)控和告警等機(jī)制传泊，特別是在MQ出現(xiàn)消息堆積的時(shí)候鼠渺，能夠第一時(shí)間通知到運(yùn)維團(tuán)隊(duì)，采取必要的手段眷细。
好了拦盹，對(duì)MQ使用的規(guī)范有深入的了解之后，我們接下來(lái)從Broker如何處理生產(chǎn)者客戶端發(fā)送的請(qǐng)求來(lái)開(kāi)始說(shuō)起溪椎，帶領(lǐng)大家來(lái)看看消息是如何產(chǎn)生的普舆。
【生產(chǎn)者客戶端如何生產(chǎn)消息】
當(dāng)生產(chǎn)者有信息要發(fā)給Broker的時(shí)候，生產(chǎn)者客戶端通過(guò)創(chuàng)建一個(gè)叫produce的請(qǐng)求校读，來(lái)講數(shù)據(jù)發(fā)送給Broker奔害，如下圖所示：
如上圖所示，會(huì)有多個(gè)客戶端同時(shí)給Broker發(fā)送消息請(qǐng)求地熄，Broker一般都是集群部署华临，會(huì)有多臺(tái)Broker服務(wù)器統(tǒng)一對(duì)外提供服務(wù)，并且一個(gè)客戶端可能會(huì)連接到多個(gè)Broker服務(wù)器上端考，具體的消息發(fā)送步驟如下：
1雅潭，生產(chǎn)者將收集的一批消息發(fā)送給Broker。對(duì)于Kafka來(lái)說(shuō)却特，無(wú)論是生產(chǎn)者還是消費(fèi)者客戶端扶供，消息總是按批處理，來(lái)提升整個(gè)系統(tǒng)的吞吐量裂明。
2椿浓，Broker從接受緩存隊(duì)列中出隊(duì)消息數(shù)據(jù)。
3闽晦，消息被保存到主題中扳碍，在主題內(nèi)部，數(shù)據(jù)按分區(qū)來(lái)存儲(chǔ)仙蛉，我們可以講分區(qū)看成放不同蘋果的籃子笋敞。Broker接收到的批量消息總是被保存到某個(gè)確定的分區(qū)中，并且消息總是被追加到存儲(chǔ)數(shù)據(jù)文件的末尾荠瘪。
4夯巷，當(dāng)Broker成功保存了數(shù)據(jù)之后，會(huì)發(fā)送響應(yīng)給生產(chǎn)者客戶端哀墓。
以上就是生產(chǎn)者客戶端發(fā)送消息的過(guò)程趁餐，接下來(lái)讓我們將目標(biāo)移動(dòng)到消費(fèi)者客戶端，看看發(fā)送到消息隊(duì)列Broker的數(shù)據(jù)篮绰，是如何被消費(fèi)的后雷。
【消費(fèi)者客戶端】
消費(fèi)者客戶端發(fā)送消息讀取請(qǐng)求到Broker，請(qǐng)求中會(huì)制定具體要讀取的主題名稱，這里需要特別注意的是喷面，Kafka實(shí)現(xiàn)了發(fā)布和訂閱模式星瘾，因此一個(gè)消費(fèi)者對(duì)消息的消費(fèi)操作走孽，并不會(huì)影響消息的可用性惧辈。Kafka Broker可以同時(shí)處理數(shù)以百計(jì)的客戶端從同一個(gè)主題上讀取數(shù)據(jù)，而相互之間不會(huì)影響磕瓷。
對(duì)于基于消息隊(duì)列通信的兩端來(lái)說(shuō)盒齿，相互之間不存在基于時(shí)間的依賴（依賴有三種類型，基于時(shí)間的依賴是我們?cè)谙到y(tǒng)設(shè)計(jì)中需要重點(diǎn)考慮的模式困食，基于時(shí)間的依賴需要兩個(gè)系統(tǒng)同時(shí)在線边翁，才能正常工作），因此生產(chǎn)者生產(chǎn)消息和消費(fèi)者消費(fèi)消息其實(shí)沒(méi)有直接的關(guān)系硕盹，如下圖所示：
如上圖所示符匾，消費(fèi)者從Broker上讀取消息會(huì)分為4步，詳細(xì)的介紹如下：
1瘩例，消費(fèi)者客戶端發(fā)送消息拉取請(qǐng)求啊胶，并指定讀取消息的位移。
2垛贤，Broker從請(qǐng)求緩沖區(qū)隊(duì)列中出隊(duì)請(qǐng)求焰坪。
3，基于請(qǐng)求消息中的主題聘惦，分區(qū)和位移信息某饰，從存儲(chǔ)介質(zhì)上讀取對(duì)應(yīng)的消息數(shù)據(jù)。
4善绎，Broker將讀取到的一批消息作為響應(yīng)返回給消費(fèi)者客戶端黔漂。
通過(guò)上邊簡(jiǎn)單的介紹，希望大家對(duì)Kafka體系中的生產(chǎn)和消費(fèi)消息有一個(gè)直觀的認(rèn)識(shí)禀酱，由于筆者會(huì)在后邊的文章詳細(xì)介紹發(fā)送和消費(fèi)消息的機(jī)制瘟仿，因此這里如果你的不是很懂，沒(méi)有關(guān)系比勉，我們還會(huì)回到這些細(xì)節(jié)討論上的劳较。
主題和分區(qū)這兩個(gè)概念在前邊的內(nèi)容中出現(xiàn)過(guò)，但是筆者并沒(méi)有做過(guò)多的解釋浩聋，這兩個(gè)概念是理解Kafka工作原理的基石观蜗，咱們接下來(lái)就詳細(xì)說(shuō)說(shuō)主題和分區(qū)的概念。
【Kafka消息隊(duì)列的主題和分區(qū)】
在上一篇文章中衣洁，筆者介紹過(guò)Kafka的消息數(shù)據(jù)保存在Broker中墓捻，并且Kafka提供的持久化機(jī)制可以讓我們存儲(chǔ)幾乎無(wú)上限的key-value數(shù)據(jù)，除了持久化消息數(shù)據(jù)，Kafka還提供了跨節(jié)點(diǎn)的數(shù)據(jù)冗余，來(lái)提升數(shù)據(jù)的可靠性廉丽，特別是在某臺(tái)Broker出現(xiàn)磁盤故障悄窃，不至于造成數(shù)據(jù)丟失。
具體來(lái)說(shuō)放吩，Kafka Broker使用文件系統(tǒng)來(lái)存儲(chǔ)消息數(shù)據(jù)，并且從生產(chǎn)者客戶端發(fā)送的新消息會(huì)被追加到文件的末尾羽杰。邏輯上來(lái)講渡紫，主題是磁盤上的一個(gè)文件夾，這個(gè)文件夾中保存了所有的數(shù)據(jù)文件考赛，而寫入數(shù)據(jù)到某個(gè)主題就是給和主題名相同的文件夾中的數(shù)據(jù)文件追加消息記錄惕澎。
注：Kafka接受到的消息數(shù)據(jù)是字節(jié)碼，并且Broker對(duì)數(shù)據(jù)不做任何變動(dòng)颜骤，直接將字節(jié)碼保存到磁盤上唧喉。對(duì)于消費(fèi)者客戶端來(lái)說(shuō)，請(qǐng)求消息數(shù)據(jù)返回的也是字節(jié)碼忍抽，和發(fā)送端發(fā)送的數(shù)據(jù)基本一致八孝。Broker處理的直接是字節(jié)碼，因?yàn)闆](méi)有序列化和反序列化這樣的操作梯找，因此Kafka Broker的處理性能會(huì)非常高唆阿。
主題的數(shù)據(jù)會(huì)被分成多個(gè)分區(qū)來(lái)保存，分區(qū)從編號(hào)0開(kāi)始锈锤，因此如果我們的主體在創(chuàng)建的時(shí)候指定了分區(qū)數(shù)量是3驯鳖，那么分區(qū)編號(hào)分別是0，1久免，2浅辙。Kafka通過(guò)把分區(qū)編號(hào)附加到主題名稱上，在主題所代表的文件夾中創(chuàng)建對(duì)應(yīng)的子文件夾阎姥，比如yunpan-0记舆，yunpan-1，yunpan-2（yunpan是筆者創(chuàng)建的主題名稱）呼巴。
Broker有個(gè)叫l(wèi)og.dirs的配置項(xiàng)泽腮，指定了數(shù)據(jù)文件的目錄路徑，比如在筆者的macOS上衣赶，log.dirs的值如下圖所在的配置文件截圖所示：
基于這個(gè)目錄诊赊，我們就能找到具體的日志文件，主題和分區(qū)的關(guān)系府瞄，比如筆者在本地有second-topic這么個(gè)主題碧磅，并且指定了分區(qū)數(shù)量為2，那么從文件系統(tǒng)中就可以看到有兩個(gè)對(duì)應(yīng)的子文件夾，及數(shù)據(jù)文件的關(guān)系如下圖所示：
通過(guò)上邊的目錄結(jié)構(gòu)鲸郊，你就能看到這個(gè)叫second-topic的主題和兩個(gè)分區(qū)（0丰榴，1）最終會(huì)產(chǎn)生second-topic-0和second-topic-1這樣的文件夾結(jié)構(gòu)。從這個(gè)實(shí)際生成的文件夾結(jié)構(gòu)上看秆撮，我們說(shuō)主題只是一個(gè)邏輯的文件夾四濒，而分區(qū)是存儲(chǔ)單元一點(diǎn)都不為過(guò)啊。
對(duì)于Kafka來(lái)說(shuō)像吻，分區(qū)數(shù)量代表這并發(fā)度峻黍，在大部分場(chǎng)景下复隆，分區(qū)數(shù)量越多拨匆，并發(fā)度越高，同時(shí)也意味著吞吐量的提升挽拂。作為整個(gè)消息中間件唯一的存儲(chǔ)介質(zhì)惭每，分區(qū)這種方式可以極大的提升整個(gè)Kafka集群的數(shù)據(jù)存儲(chǔ)量和穩(wěn)定性，消息會(huì)被分發(fā)到不同的分區(qū)上亏栈，不同的分區(qū)在多節(jié)點(diǎn)集群中意味著不同的機(jī)器台腥。
由于整個(gè)集群的存儲(chǔ)容量不再受限于一臺(tái)Broker機(jī)器的磁盤大小，因此整個(gè)集群存儲(chǔ)數(shù)據(jù)量近乎無(wú)限绒北。另外通過(guò)使用數(shù)據(jù)在多個(gè)節(jié)點(diǎn)之間復(fù)制機(jī)制黎侈，單節(jié)點(diǎn)的故障不會(huì)造成數(shù)據(jù)丟失，整個(gè)集群的數(shù)據(jù)可靠性得到保障闷游。
我們會(huì)在后續(xù)的文章中討論負(fù)載分發(fā)峻汉，復(fù)制機(jī)制，leader選舉等機(jī)制脐往，以及多級(jí)存儲(chǔ)體系功能休吠，我們就可以把冷數(shù)據(jù)同步到外部系統(tǒng)上，讓Kafka集群只保存熱數(shù)據(jù)业簿，降低磁盤的占用空間瘤礁，也提升的系統(tǒng)的穩(wěn)定性。
讀到這里梅尤，你可能會(huì)問(wèn)柜思，Kafka是如何將給消息找到對(duì)應(yīng)的分區(qū)呢？其實(shí)啊巷燥，在生產(chǎn)者客戶端赡盘，有一個(gè)叫分區(qū)分配攔截器的組件，我們可以自定義這個(gè)組件矾湃，消息在發(fā)送到Broker之前亡脑，通過(guò)這個(gè)攔截器會(huì)計(jì)算出分區(qū)編號(hào)，當(dāng)Broker收到消息的時(shí)候，只需要按照消息的數(shù)據(jù)中制定的分區(qū)編號(hào)霉咨，來(lái)保存到對(duì)應(yīng)文件夾下的數(shù)據(jù)文件中蛙紫。
生產(chǎn)者客戶端配置的攔截器有三種方式來(lái)給消息指定分區(qū)編號(hào)：
1，如果待發(fā)送消息的key不為null途戒，那么Kafka就可以確定消息發(fā)送的分區(qū)坑傅，計(jì)算方式為獲取key，進(jìn)行哈希計(jì)算喷斋，然后和分區(qū)的總數(shù)進(jìn)行取模唁毒，因此筆者在開(kāi)篇提到的保序最佳實(shí)踐中，如果后續(xù)消息都設(shè)置了相同的key星爪，那么消息會(huì)被發(fā)送到相同的分區(qū)上浆西。
2，當(dāng)我們?cè)诖a中直接通過(guò)ProduceRecord來(lái)構(gòu)建待發(fā)送消息的時(shí)候顽腾，我們可以直接給這個(gè)消息對(duì)象制定分區(qū)編號(hào)近零，Broker會(huì)基于這個(gè)指定的分區(qū)編號(hào)來(lái)講數(shù)據(jù)保存到對(duì)應(yīng)的文件夾。
3抄肖，如果消息沒(méi)有設(shè)置key久信，也就是說(shuō)key是null，并且未人為指定分區(qū)編號(hào)漓摩，那么消息的生產(chǎn)者端會(huì)采用輪流的方式來(lái)發(fā)送消息到所有的分區(qū)上裙士。
到這里為止我們對(duì)Kafka如何把消息映射到分區(qū)上已經(jīng)非常清楚了，接下來(lái)我們來(lái)聊聊新消息總是被追加到數(shù)據(jù)文件尾部這個(gè)機(jī)制管毙⊥茸担回顧一下筆者展示的在自己機(jī)器上看到的文件夾中的數(shù)據(jù)文件，是以.log為文件擴(kuò)展名锅风。但是這個(gè)log文件和開(kāi)發(fā)人員打印的日志不太一樣酥诽，和我們?cè)贙ubernetes中查看的容器日志也不一樣。
在Kafka或者大部分?jǐn)?shù)據(jù)庫(kù)系統(tǒng)中皱埠，比如MYSQL有redo log和bin log肮帐，redis有append only log，日志log這個(gè)概念代表的是事務(wù)日志边器，表示造成數(shù)據(jù)庫(kù)狀態(tài)變化的一系列事件训枢。因此每個(gè)分區(qū)的文件夾中都分別保存了自己的事務(wù)日志，這個(gè)時(shí)候你可能會(huì)說(shuō)忘巧，如果是這種機(jī)制恒界，日志文件的size豈不是不斷增長(zhǎng)，我們后邊會(huì)介紹rention的機(jī)制砚嘴。
當(dāng)Broker將收到的消息追加到日志文件末尾時(shí)十酣，會(huì)給每個(gè)消息分配一個(gè)叫offset的id編號(hào)涩拙，offset從0開(kāi)始計(jì)數(shù)，被增加一條消息就加1耸采，offset是消息在日志文件中的邏輯位置兴泥。而”邏輯“一次的含義是，offset代表的是消息是日志文件中的第N條消息虾宇，由于每條消息的size都可能不一致搓彻，因此消息的物理位置和所有前邊消息的size有關(guān)系，我們會(huì)在后續(xù)的文章中詳細(xì)介紹Broker是如何在日志文件中確定消息的物理位置嘱朽。下圖展示了給剛接收到的新消息分配offset的原理：
如上圖所示旭贬，新消息總是被追加到日志文件的末尾，Kafka會(huì)保證同一個(gè)分區(qū)上消息的有序性搪泳，但是無(wú)法保證跨分區(qū)的有序性稀轨。這個(gè)也不難理解，同一個(gè)分區(qū)上的消息森书，總是按offset有序排列靶端。時(shí)間具備單調(diào)有序谎势，因此我們很自然就會(huì)想到按時(shí)間有序凛膏。Kafka中每條消息有兩個(gè)時(shí)間屬性，arrival time（達(dá)到時(shí)間）和 event time（時(shí)間發(fā)生時(shí)間）脏榆，這兩個(gè)時(shí)間的業(yè)務(wù)含義不太一樣猖毫，我們會(huì)在后續(xù)章節(jié)詳細(xì)介紹。
消費(fèi)者客戶端通過(guò)offsets來(lái)維護(hù)消費(fèi)進(jìn)度须喂，這樣的話吁断，Broker就可以為每個(gè)消費(fèi)者按照offset單調(diào)遞增的方式來(lái)讀取下一批消息，如下圖所示：
如上圖所示坞生，如果消費(fèi)A第一次成功消費(fèi)了0-5位移的多條消息仔役，那么下一次消費(fèi)讀取到的數(shù)據(jù)就從offset6開(kāi)始，Broker為每個(gè)消費(fèi)者維護(hù)了offset位移信息是己，這些信息被保存在一個(gè)內(nèi)部的叫_consumer_offsets的主題中又兵。
讀到這里，大家可能會(huì)問(wèn)卒废，那么我們應(yīng)該如何確定分區(qū)的數(shù)量呢沛厨？從筆者過(guò)往的經(jīng)驗(yàn)來(lái)看，確定準(zhǔn)確的分區(qū)數(shù)量和數(shù)據(jù)量有很大的關(guān)系摔认。我們需要考慮特定主題會(huì)接收到的最大數(shù)據(jù)量逆皮，因此簡(jiǎn)單看數(shù)據(jù)量越大，我們需要的分區(qū)越多参袱，并且吞吐量也會(huì)越好电谣，但是系統(tǒng)架構(gòu)設(shè)計(jì)導(dǎo)出充斥著取舍秽梅，而確定分區(qū)數(shù)量也不列外，沒(méi)有一勞永逸的事情剿牺。
具體來(lái)說(shuō)风纠，增加分區(qū)數(shù)量會(huì)造成數(shù)據(jù)同步機(jī)制的負(fù)擔(dān)增加，整個(gè)集群的網(wǎng)絡(luò)上會(huì)有更多的TCP連接和數(shù)據(jù)牢贸。另外消費(fèi)者端處理消息的效率也會(huì)影響吞吐量竹观，如果我們的消費(fèi)端處理的非常緩慢，那么短期內(nèi)增加分區(qū)可能提升吞吐量潜索，但是總會(huì)到天花板臭增。
基于筆者過(guò)往的經(jīng)驗(yàn)，有這么些最佳時(shí)間可以分享：1竹习，我們一開(kāi)始需要?jiǎng)?chuàng)建盡可能多個(gè)分區(qū)數(shù)量誊抛，具體來(lái)說(shuō)對(duì)于生產(chǎn)環(huán)境，這個(gè)數(shù)量可以是30整陌，因?yàn)?0可以被很多數(shù)整除拗窃，這就意味著分區(qū)可以更加平均的分配到多個(gè)Broker節(jié)點(diǎn)上，而分區(qū)被分配的越均衡泌辫，數(shù)據(jù)就可能越平衡分配随夸。整個(gè)集群的吞吐量就越高。
好了震放，今天的這篇文章就這么多內(nèi)容了宾毒，接下來(lái)筆者會(huì)介紹Kafka的數(shù)據(jù)管理機(jī)制，主要介紹數(shù)據(jù)是如何在磁盤上保存以及數(shù)據(jù)的過(guò)期清理機(jī)制殿遂，敬請(qǐng)期待诈铛！
