日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

微博怎么注冊 微博是干什么用的( 二 )

云知道




通過 KoP 協(xié)議可以落地 Pulsar 并原生支持新浪現(xiàn)有的 Kafka 客戶端，也可以解決新浪 Kafka 團(tuán)隊(duì)在 Kafka 上的運(yùn)維痛點(diǎn) 。于是團(tuán)隊(duì)開始調(diào)研和實(shí)踐 KoP 組件 。在此過程中，團(tuán)隊(duì)也遇到了一些問題 ， 其中一個(gè)主要挑戰(zhàn)就是 KoP 低版本兼容性問題 。
部署問題與解決方案
KoP 低版本兼容性問題
新浪 Kafka 集群中一些較重要的集群仍在使用較老的 Kafka 版本（如 0.10），因此在調(diào)研與實(shí)踐中需要兼容較老版本的客戶端 。KoP 只支持 1.0 及以后的版本 。經(jīng)過總結(jié)，團(tuán)隊(duì)發(fā)現(xiàn)了以下細(xì)節(jié)問題并給出對應(yīng)解決方案 。
低版本認(rèn)證不兼容
客戶端需要通過認(rèn)證才可以訪問新浪的認(rèn)證集群，與服務(wù)端交互 。在 Kafka 1.0 版本之前，客戶端與服務(wù)端的認(rèn)證交互是通過 V0 版本的 SaslHandshakeRequest 請求完成的，之后的 token 信息由 SASL tokens（不需要 Kafka request headers）包裝，這是一些不透明的數(shù)據(jù)包 。所以團(tuán)隊(duì)需要在 KoP 中手動處理這些數(shù)據(jù)包才能完成認(rèn)證工作 。
在 Kafka 1.0 版本之后，認(rèn)證交互通過 V1 版本的 SaslHandshakeRequest 請求完成 ， token 信息則由 SaslAuthenticateRequest 請求封裝 。KoP 處理時(shí)會直接解析 token 的協(xié)議頭 。KoP 的低版本認(rèn)證不兼容問題主要出現(xiàn)在 token 信息這個(gè)層面 ， 團(tuán)隊(duì)需要通過重構(gòu)來避免 KoP 直接解析令牌的協(xié)議頭 ， 從而順利處理舊版本的不透明數(shù)據(jù)包 。詳細(xì)代碼參見 GitHub 。(https://github.com/streamnative/kop/pull/676) 。
日志協(xié)議兼容性問題

微博怎么注冊 微博是干什么用的



以上是 Kafka 消息協(xié)議的幾個(gè)版本示意，從左至右分別為 V0、V1、V2 。Kafka 0.10 版本之前使用 V0 版消息協(xié)議，0.10 版本改用 V1 版，0.11 之后改用 V2 版 。V1 版本相比 V0 版本新增了時(shí)間戳；V2 版本改動較大，從 message set 變成了 RecordBatch，后者內(nèi)部還封裝了很多 Record 。上圖中各個(gè)方框內(nèi)都是協(xié)議中的關(guān)鍵字段 。V2 版本開始內(nèi)部消息都使用相對位移，RecordBatch 的元數(shù)據(jù)部分只需放置起始的絕對位移 。
于是不同版本之間生產(chǎn)消費(fèi)時(shí)就會存在日志協(xié)議兼容性問題 。例如一個(gè)高版本的生產(chǎn)者生產(chǎn)消息后，低版本的消費(fèi)者是無法解析新版日志協(xié)議的 ， 自然只會報(bào)錯而無法消費(fèi) 。為此需要引入跨版本消息轉(zhuǎn)換功能，才能讓低版本讀取高版本的消息 。但如果生產(chǎn)者是低版本，消費(fèi)者是高版本，由于協(xié)議是向下兼容的，所以數(shù)據(jù)消費(fèi)不會存在問題，不需要轉(zhuǎn)換 。
那么 KoP 是如何處理生產(chǎn)者請求的呢？Kafka 客戶端發(fā)來生產(chǎn)者請求時(shí) ， KoP 解析請求后，Handler 線程會調(diào)用 ReplicaManager 主鍵，追加 Kafka 的 Records 。這個(gè)主鍵與 Kafka 中的副本管理器是對應(yīng)的，做了映射 。
io.streamnative.pulsar.handlers.kop.storage.ReplicaManager#appendRecords復(fù)制代碼
每個(gè)分區(qū)對應(yīng)一個(gè) PartitionLog，映射了 Kafka 里面的 loggingScala 類對應(yīng)，每一個(gè) KoP broker 中都有一個(gè) PartitionLogManager 來管理 PartitionLog 。要將 Kafka Records 處理為消息寫入 Bookie，這里的問題就是如何從 Records 編碼成 Messages 。
io.streamnative.pulsar.handlers.kop.storage.PartitionLog#appendRecords復(fù)制代碼

微博怎么注冊 微博是干什么用的



PartitionLog 在追加 Kafka 的 Records 時(shí)，會執(zhí)行 EntryFormatter 的 encode 過程 io.streamnative.pulsar.handlers.kop.format.EntryFormatter#encode 。編碼之后會通過 Pulsar broker 的 Persistenttopic 組件 org.apache.pulsar.broker.service.persistent.PersistentTopic#publishMessage來 publishMessage 。在 EntryFormat 過程中將 Kafka Records 轉(zhuǎn)換為 Pulsar 消息 。然后用存儲層 ManagedLedger 將消息發(fā)布為 Bookie 可識別的 entry 寫入 Bookie 。這里的關(guān)鍵就是 EntryFormat 編碼過程 。下圖引據(jù)了 entryFormat 的介紹，可以看到其取值可選 kafka、mixed_kafka 和 pulsar ， 默認(rèn)為 Pulsar 。

推薦閱讀