在正式分享 2.6.1 版本更新細(xì)節(jié)之前纠修，冉小龍首先為我們分享了兩個(gè)相關(guān) PIP 的內(nèi)容。
一個(gè)是 PIP-47 中關(guān)于「基于時(shí)間來進(jìn)行版本更新」的計(jì)劃厂僧。該 PIP 提出后扣草，從 2.5.0 版本到目前即將發(fā)布的 2.6.1 版本中，時(shí)間更短颜屠、發(fā)布頻率更高成為最突出的特點(diǎn)辰妙。同時(shí)反饋周期快，基本是每三個(gè)月更新一個(gè)大版本甫窟。這樣用戶也可以大概了解版本的一個(gè)更新周期上岗，增進(jìn)了項(xiàng)目透明度。
另一個(gè)是 PIP-69 中計(jì)劃在 Go Client 中集成 schema 相關(guān)的功能和特性蕴坪，更多詳情介紹可以參考下方：https://github.com/apache/pulsar/wiki/PIP-69%3A-Schema-design-for-Go-client。
版本更新情況
此次 2.6.1 版本更新接收了來自社區(qū)的 112 次 commits敬锐，覆蓋 broker背传、Pulsar Functions、Go Function台夺、Pulsar SQL径玖、Schema、Java/CPP Client 等層面颤介。同時(shí)截止目前 Apache Pulsar 項(xiàng)目已有 6400+ star梳星、1500+ fork，以及即將超過 300 人的 contributor 數(shù)量滚朵。
接下來就簡(jiǎn)單介紹一些 2.6.1 版本中的更新功能吧冤灾。
修復(fù) Key_Shared 中 stick hash range 沖突的問題
Key_Shared 訂閱模式可以保證用戶在訂閱到某個(gè) topic 時(shí)，可以指定 producer message key辕近。消息會(huì)根據(jù)指定 key 的不同韵吨，通過 hash range 有序發(fā)送到不同的 consumer。
此 PR 主要是在 broker 端添加一個(gè) check 機(jī)制移宅，來避免 stick hash range 沖突归粉。Stick hash range 的范圍是 0-65535椿疗，導(dǎo)致該錯(cuò)誤的主要原因是因?yàn)樵?broker 端，沒有對(duì) stick hash range 中的 start 和 end 位置進(jìn)行檢查糠悼。
正常情況下届榄，是不允許 start 大于 end 的位置。在 2.6.1 中倔喂，我們加入了相應(yīng)的 check 機(jī)制铝条，來避免出現(xiàn) range 沖突的問題。
在 Key_Shared 中對(duì) payload 進(jìn)行解壓縮
一般為了節(jié)約網(wǎng)絡(luò)帶寬滴劲，在創(chuàng)建 producer 時(shí)攻晒，會(huì)根據(jù)不同場(chǎng)景選擇不同的壓縮類型。Consumer 端使用了 Key_Shared 訂閱模型來訂閱 topic班挖，在消息中鲁捏，標(biāo)注消息的重要字段可能是 payload 字段。
在之前版本中是沒有針對(duì)在 Key_Shared 訂閱模式下對(duì) payload 進(jìn)行解壓縮的功能萧芙，此 PR 則是填補(bǔ)了這項(xiàng)功能给梅。
修復(fù)在關(guān)閉 consumer 時(shí)的競(jìng)態(tài)條件
根據(jù)上圖左邊圈出來的部分可以看出，message backlog 一直處于增加的狀態(tài)双揪。Backlog 就是在消息生產(chǎn)—消費(fèi)過程中动羽，沒有被 consumer 消費(fèi)掉的消息堆積，正常情況下渔期，producer 生產(chǎn)消息與 consumer 消費(fèi)消息的速率大致是一樣的运吓。但是從上圖中的遞增狀態(tài)的 backlog 就表明了，消息生產(chǎn)消費(fèi)過程中出現(xiàn)了消費(fèi)不均衡狀態(tài)疯趟。
此 PR 修復(fù)了當(dāng)宕機(jī)重啟后拘哨，消息生產(chǎn)消費(fèi)錯(cuò)開產(chǎn)生的競(jìng)態(tài)條件，做法就是在中間加一些檢查機(jī)制信峻。在 consumer 要打開一個(gè)連接時(shí)倦青，添加狀態(tài)檢查，如果當(dāng)前 connection 的狀態(tài)為 closing 或者 closed 狀態(tài)時(shí)盹舞，我們不需要發(fā)送 subscribe 的 command 到 broker 即可产镐。
使用標(biāo)準(zhǔn)主機(jī)名作為 worker 的默認(rèn)值
在 Java 8 和 Java 11 中，Get Hostname 返回的值是不一樣的踢步。即 Java 8 中返回的是標(biāo)準(zhǔn)主機(jī)名癣亚，Java 11 中返回的是簡(jiǎn)單主機(jī)名。此 PR 就是在 Java 11 中添加了可以獲取標(biāo)準(zhǔn)主機(jī)名的方法.
修復(fù) 2.6.0 引入的向后兼容問題
在 pulsar 的整個(gè)版本迭代中获印，向后兼容是一個(gè)很重要的保證逃糟。同時(shí)在是否合并 PR 的過程中也是一個(gè)十分重要的決定因素。
此 PR 中提到的向后兼容問題是由于在 2.5.0 中支持了一個(gè)功能，允許多個(gè) Pulsar cluster 去使用同一個(gè) BookKeeper 的 cluster绰咽，所以在 2.5.0 的 broker 中菇肃，會(huì)響應(yīng)帶有 BookKeeperMetadataServiceUri 的請(qǐng)求，但是 client 返回的結(jié)果卻是 null取募。
所以當(dāng) Function worker 和 broker 分開部署時(shí)琐谤，把 Function worker 和 broker 單獨(dú)從 2.5.0 更新到 2.6.0 時(shí)，會(huì)返回空指針異常玩敏。
修復(fù)的方式就是在初始化 Function worker 時(shí)斗忌，對(duì) BookKeeperMetadataServiceUri 的 value 進(jìn)行檢查，判斷它是否為 null旺聚。
優(yōu)化 Pulsar Function 的加密配置
在之前的版本中织阳，F(xiàn)unction worker 與 TLS 相關(guān)的配置文件/文檔等介紹不太全面，此 PR 就是對(duì)此問題進(jìn)行了同步優(yōu)化砰粹。
主要是在 TLS transport encryption唧躲、Authentication Provider 和 Authorization Provider 上進(jìn)行了部分修改，可以大致參考下圖碱璃。
更多關(guān)于授權(quán)和認(rèn)證相關(guān)的內(nèi)容弄痹，可以參考之前 TGIP-CN 的直播 ?? 深入了解 Pulsar 認(rèn)證和授權(quán)機(jī)制。
在 pulsar-perf 中支持 tlsAllowInsecureConnectio
此 PR 在 ./bin/pulsar-perf produce命令中增加了允許不信任連接的功能嵌器，作用于 producer肛真、consumer 和 reader 端。
處理在創(chuàng)建非持久性 cursor 時(shí)的錯(cuò)誤
上圖中爽航，當(dāng)用戶在創(chuàng)建非持久性 cursor 失敗時(shí)蚓让，會(huì)返回一個(gè) NPE 的 exception，這是因?yàn)楫?dāng)創(chuàng)建非持久性 cursor 失敗時(shí)讥珍，我們?nèi)匀粫?huì)去創(chuàng)建一個(gè) subscription instance 對(duì)象历极。
這將導(dǎo)致該 topic 的引用計(jì)數(shù)加一，當(dāng)用戶想要?jiǎng)h除這個(gè) topic 時(shí)串述，由于引用計(jì)數(shù)沒有被清零，所以即使使用 --force 強(qiáng)制去刪除寞肖，也刪除不掉纲酗，導(dǎo)致 topic 引用技術(shù)增加。
此 PR 就是在創(chuàng)建非持久性 cursor 失敗的時(shí)候新蟆，返回一個(gè) failedFuture 對(duì)象觅赊，而不是去創(chuàng)建一個(gè) subscription instance。
創(chuàng)建新 ledger 時(shí)引發(fā) NPE 而導(dǎo)致生產(chǎn)者卡死的問題
由于無法解析網(wǎng)絡(luò)地址琼稻，因此在創(chuàng)建 ledger 時(shí)會(huì)引發(fā) NPE吮螺。如果在添加超時(shí)任務(wù)之前引發(fā)了 NPE，則超時(shí)機(jī)制不起作用。無法解析的網(wǎng)絡(luò)地址在 Kubernetes 環(huán)境中很常見鸠补。當(dāng) bookie pod 或工作程序節(jié)點(diǎn)重新啟動(dòng)時(shí)萝风，可能會(huì)發(fā)生這種情況。
此 PR 的解決邏輯在于三個(gè)層面紫岩，即捕獲 NPE Exception规惰、觸發(fā)超時(shí)任務(wù)時(shí)執(zhí)行回調(diào)策略、以及檢測(cè) CreationLedger 的狀態(tài)泉蝌。
完善 Window Function 相關(guān)的文檔
在整個(gè)流處理數(shù)據(jù)中歇万，經(jīng)常需要以聚合方式進(jìn)行數(shù)據(jù)收集和處理，通常以時(shí)間或者是數(shù)據(jù)數(shù)量為計(jì)量單位來進(jìn)行勋陪，這種每個(gè)集合就屬于 window贪磺。
在 Pulsar Functions 中，window function 主要有三個(gè)重要概念诅愚。
- Trigger（觸發(fā)器）：決定當(dāng)前 window 何時(shí)被計(jì)算/執(zhí)行/刪除等操作寒锚。每個(gè) window 都有相應(yīng)觸發(fā)器去追蹤狀態(tài)。
- Evictor（過濾器）：當(dāng) window 被 trigger 觸發(fā)后呻粹，在 Window Function 處理之前會(huì)刪除窗口中不重要的元素壕曼。需要注意的是，Evictor 不是一個(gè)必需因素等浊，可存在可不存在腮郊。
- Watermark（衡量線）：屬于數(shù)據(jù)本身的隱藏屬性，設(shè)定一些機(jī)制筹燕，保證在某些條件下必須觸發(fā)某些狀態(tài)轧飞。
增添 OAuth2 功能
OAuth2 屬于 2.6.1 版本中新增的一個(gè)大功能。當(dāng)前 Pulsar 支持的 Authentication Providers 主要有以下幾種：
- TLS Authentication
- Athenz
- Kerbos
- JSON Web Token Authentication
整個(gè) OAuth2 相當(dāng)于授權(quán)框架/授權(quán)標(biāo)準(zhǔn)撒踪，它可以使用第三方應(yīng)用程序/客戶端獲得 HTTP 服務(wù)上的賬戶信息權(quán)限訪問过咬，通過用戶信息委派給托管用戶信息的一些服務(wù)器進(jìn)行工作。簡(jiǎn)單來說就是為外部應(yīng)用提供一個(gè)授權(quán)流程制妄，更偏向于個(gè)人定制化特色掸绞，具體操作步驟如下圖：
目前支持 OAuth2 功能的主要有：
- Java Client（Client 版本在 2.6.1 及以上）
- CPP Client
- Go Client
- pulsar-admin
- pulsar-perf
- pulsar-client
- pulsarctl(CLI && admin API)
總結(jié)
此次直播主要在 Pulsar 版本更新細(xì)節(jié)中簡(jiǎn)明扼要地分享了幾個(gè)重要細(xì)節(jié)，2.6.1 版本也將在未來幾天內(nèi)正式發(fā)布上線耕捞，敬請(qǐng)期待衔掸。更多直播細(xì)節(jié)可點(diǎn)擊下方視頻回放觀看：https://v.qq.com/x/page/y3137om2z9z.html。
