在正式分享 2.6.1 版本更新細(xì)節(jié)之前，冉小龍首先為我們分享了兩個(gè)相關(guān) PIP 的內(nèi)容。
一個(gè)是 PIP-47 中關(guān)于「基于時(shí)間來(lái)進(jìn)行版本更新」的計(jì)劃。該 PIP 提出后，從 2.5.0 版本到目前即將發(fā)布的 2.6.1 版本中，時(shí)間更短、發(fā)布頻率更高成為最突出的特點(diǎn)。同時(shí)反饋周期快，基本是每三個(gè)月更新一個(gè)大版本。這樣用戶(hù)也可以大概了解版本的一個(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 版本更新接收了來(lái)自社區(qū)的 112 次 commits，覆蓋 broker、Pulsar Functions、Go Function、Pulsar SQL、Schema、Java/CPP Client 等層面。同時(shí)截止目前 Apache Pulsar 項(xiàng)目已有 6400+ star、1500+ fork，以及即將超過(guò) 300 人的 contributor 數(shù)量。
接下來(lái)就簡(jiǎn)單介紹一些 2.6.1 版本中的更新功能吧。
修復(fù) Key_Shared 中 stick hash range 沖突的問(wèn)題
Key_Shared 訂閱模式可以保證用戶(hù)在訂閱到某個(gè) topic 時(shí)，可以指定 producer message key。消息會(huì)根據(jù)指定 key 的不同，通過(guò) hash range 有序發(fā)送到不同的 consumer。
此 PR 主要是在 broker 端添加一個(gè) check 機(jī)制，來(lái)避免 stick hash range 沖突。Stick hash range 的范圍是 0-65535，導(dǎo)致該錯(cuò)誤的主要原因是因?yàn)樵?broker 端，沒(méi)有對(duì) stick hash range 中的 start 和 end 位置進(jìn)行檢查。
正常情況下，是不允許 start 大于 end 的位置。在 2.6.1 中，我們加入了相應(yīng)的 check 機(jī)制，來(lái)避免出現(xiàn) range 沖突的問(wèn)題。
在 Key_Shared 中對(duì) payload 進(jìn)行解壓縮
一般為了節(jié)約網(wǎng)絡(luò)帶寬，在創(chuàng)建 producer 時(shí)，會(huì)根據(jù)不同場(chǎng)景選擇不同的壓縮類(lèi)型。Consumer 端使用了 Key_Shared 訂閱模型來(lái)訂閱 topic，在消息中，標(biāo)注消息的重要字段可能是 payload 字段。
在之前版本中是沒(méi)有針對(duì)在 Key_Shared 訂閱模式下對(duì) payload 進(jìn)行解壓縮的功能，此 PR 則是填補(bǔ)了這項(xiàng)功能。
修復(fù)在關(guān)閉 consumer 時(shí)的競(jìng)態(tài)條件
根據(jù)上圖左邊圈出來(lái)的部分可以看出，message backlog 一直處于增加的狀態(tài)。Backlog 就是在消息生產(chǎn)—消費(fèi)過(guò)程中，沒(méi)有被 consumer 消費(fèi)掉的消息堆積，正常情況下，producer 生產(chǎn)消息與 consumer 消費(fèi)消息的速率大致是一樣的。但是從上圖中的遞增狀態(tài)的 backlog 就表明了，消息生產(chǎn)消費(fèi)過(guò)程中出現(xiàn)了消費(fèi)不均衡狀態(tài)。
此 PR 修復(fù)了當(dāng)宕機(jī)重啟后，消息生產(chǎn)消費(fèi)錯(cuò)開(kāi)產(chǎn)生的競(jìng)態(tài)條件，做法就是在中間加一些檢查機(jī)制。在 consumer 要打開(kāi)一個(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 引入的向后兼容問(wèn)題
在 pulsar 的整個(gè)版本迭代中，向后兼容是一個(gè)很重要的保證。同時(shí)在是否合并 PR 的過(guò)程中也是一個(gè)十分重要的決定因素。
此 PR 中提到的向后兼容問(wèn)題是由于在 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 分開(kāi)部署時(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ì)此問(wèn)題進(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)用戶(hù)在創(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)用戶(hù)想要?jiǎng)h除這個(gè) topic 時(shí)，由于引用計(jì)數(shù)沒(méi)有被清零，所以即使使用 --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èn)題
由于無(wú)法解析網(wǎng)絡(luò)地址，因此在創(chuàng)建 ledger 時(shí)會(huì)引發(fā) NPE。如果在添加超時(shí)任務(wù)之前引發(fā)了 NPE，則超時(shí)機(jī)制不起作用。無(wú)法解析的網(wǎng)絡(luò)地址在 Kubernetes 環(huán)境中很常見(jià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ì)量單位來(lái)進(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（過(guò)濾器）：當(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)用程序/客戶(hù)端獲得 HTTP 服務(wù)上的賬戶(hù)信息權(quán)限訪問(wèn)，通過(guò)用戶(hù)信息委派給托管用戶(hù)信息的一些服務(wù)器進(jìn)行工作。簡(jiǎn)單來(lái)說(shuō)就是為外部應(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 版本也將在未來(lái)幾天內(nèi)正式發(fā)布上線，敬請(qǐng)期待。更多直播細(xì)節(jié)可點(diǎn)擊下方視頻回放觀看：https://v.qq.com/x/page/y3137om2z9z.html。
