1.2.1 消息和批次
- Kafka的數(shù)據(jù)單元被稱(chēng)為消息。
- 消息被分批次寫(xiě)入kafka，批次就是一組消息，這些消息屬于同一個(gè)主題和分區(qū)。
1.2.3 主題和分區(qū)
- Kafka消息通過(guò)主題進(jìn)行分類(lèi)。
- 主題可以被分為若干個(gè)分區(qū)。
主題和分區(qū)
1.2.4 生產(chǎn)者消費(fèi)者
- 會(huì)有一個(gè)或多個(gè)消費(fèi)者共同讀取一個(gè)主題。
- 群組保證每個(gè)分區(qū)只能被一個(gè)消費(fèi)者使用。
消費(fèi)者
1.2.5 broker和集群
- 一個(gè)獨(dú)立的Kafka服務(wù)器被稱(chēng)為broker。
- broker是集群的組成部分。每個(gè)集群都有一個(gè)broker充當(dāng)了集群控制器的角色。
- 一個(gè)分區(qū)從屬于一個(gè)broker，該broker被稱(chēng)為分區(qū)的首領(lǐng)。
broker
3.1 生產(chǎn)者
生產(chǎn)者
- 可以同步發(fā)送消息，也可以異步發(fā)送消息
3.5.2 使用Avro序列化
- 當(dāng)負(fù)責(zé)寫(xiě)消息的應(yīng)用程序使用了新的schema，負(fù)責(zé)讀消息的應(yīng)用程序可以繼續(xù)處理消息而無(wú)需任何改動(dòng)。
- 如果變了，原來(lái)的get方法就會(huì)返回null。
序列化反序列化
4.1.1 消費(fèi)者和消費(fèi)者群組
- 多余的消費(fèi)者只會(huì)被閑置。
4.1.2 消費(fèi)者群組和分區(qū)再均衡
- 消費(fèi)者通過(guò)向被指派為群組協(xié)調(diào)器的broker發(fā)送心跳來(lái)位置它們和群組的從屬關(guān)系以及它們對(duì)分區(qū)的所有權(quán)關(guān)系。
4.4 輪詢(xún)
while(true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecords<String, String> record : records) {
}
}
- 消費(fèi)者必須持續(xù)向Kafka進(jìn)行輪訓(xùn)，否則會(huì)被認(rèn)為已經(jīng)死亡。
4.6 提交和偏移量
- 消費(fèi)者往一個(gè)叫做_consumer_offset的特殊主題發(fā)送消息，消息里包含每個(gè)分區(qū)的偏移量。
重復(fù)處理的出現(xiàn)
- 保存記錄和偏移量保證原子性，數(shù)據(jù)可以不重
5.2 控制器
- 控制器其實(shí)就是一個(gè)broker，只是還負(fù)責(zé)分區(qū)首領(lǐng)的選舉。
- 集群里第一個(gè)啟動(dòng)的broker通過(guò)在zookeeper里創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)/controller讓自己稱(chēng)為控制器。
- 控制器使用epoch來(lái)避免腦裂。
5.3 復(fù)制
- 每個(gè)分區(qū)都有一個(gè)首領(lǐng)副本。
- 持續(xù)請(qǐng)求得到的最新消息副本被稱(chēng)為同步的副本。
5.4 處理請(qǐng)求
- broker會(huì)在它所監(jiān)聽(tīng)的每一個(gè)端口上運(yùn)行一個(gè)Acceptor線(xiàn)程，這個(gè)線(xiàn)程會(huì)創(chuàng)建一個(gè)連接，并把它交給Processor線(xiàn)程去處理。
處理請(qǐng)求
5.4.2 獲取請(qǐng)求
- Kafka使用零復(fù)制技術(shù)向客戶(hù)端發(fā)送消息，直接把消息從文件發(fā)送到網(wǎng)絡(luò)通道。
- 還沒(méi)有被足夠多副本復(fù)制的消息被認(rèn)為是不安全的，如果首領(lǐng)崩潰，可能造成數(shù)據(jù)丟失。
broker延遲作出響應(yīng)
5.5.3 文件格式
普通消息和包裝消息
5.5.6 清理
- 為每個(gè)鍵保留最新值。
6.5.2 顯示提交偏移量
- 遇到可重試錯(cuò)誤時(shí)，提交最后一個(gè)處理成功的偏移量，然后把還沒(méi)有處理好的消息保存到緩沖區(qū)里。
- 暫停輪詢(xún)的時(shí)間不能超過(guò)幾秒鐘。
- 實(shí)現(xiàn)僅一次最簡(jiǎn)單最常用的方法就是把結(jié)果寫(xiě)到一個(gè)支持唯一鍵的系統(tǒng)里。
7.3 Kafka Connect
- 以worker進(jìn)程集群的方式運(yùn)行。
- 數(shù)據(jù)源的連接器負(fù)責(zé)從源系統(tǒng)讀取數(shù)據(jù)，并把數(shù)據(jù)對(duì)象提供給worker進(jìn)程。
- 數(shù)據(jù)池的連接器負(fù)責(zé)從worker進(jìn)程獲取數(shù)據(jù)，并把它們寫(xiě)入目標(biāo)系統(tǒng)。
7.3.4 深入理解Connect
- 連接器決定運(yùn)行多少個(gè)任務(wù)、按照任務(wù)來(lái)拆分?jǐn)?shù)據(jù)復(fù)制、從worker進(jìn)程獲取任務(wù)配置并將其傳遞下去。
- 任務(wù)負(fù)責(zé)將數(shù)據(jù)移入或移出Kafka。
- 源系統(tǒng)的任務(wù)對(duì)外部系統(tǒng)進(jìn)行輪詢(xún)并返回一些記錄，worker進(jìn)程將這些記錄發(fā)送到kafka。
- worker進(jìn)程是連接器和任務(wù)的容器。負(fù)責(zé)REST API、配置管理、可靠性、高可用性、伸縮性和負(fù)載均衡。
- Connect提供了一組數(shù)據(jù)API——它們包含了數(shù)據(jù)對(duì)象和用于買(mǎi)描述數(shù)據(jù)的schema。
- 轉(zhuǎn)換器用于將數(shù)據(jù)保存到kafka。
https://blog.csdn.net/iqifenxia/article/details/121893983
Kafka Connect 中的連接器負(fù)責(zé)從源數(shù)據(jù)存儲(chǔ)（例如數(shù)據(jù)庫(kù)）獲取數(shù)據(jù)，并以數(shù)據(jù)內(nèi)部表示將數(shù)據(jù)傳給轉(zhuǎn)換器。然后，Kafka Connect 的轉(zhuǎn)換器將這些源數(shù)據(jù)對(duì)象序列化到主題上。
11.1 什么是流處理
- 事件有序、不可變更數(shù)據(jù)記錄、事件流可重播
11.3 流式處理的設(shè)計(jì)模式
- 單個(gè)事件處理，map模式。
- 使用本地狀態(tài)。
- 多階段處理和重分區(qū)。
多階段 重分區(qū)
- 使用外部查找實(shí)現(xiàn)流表連接。
- 流與流的連接，基于窗口，窗口需要維護(hù)狀態(tài)。
流連接
