特性預覽：Apache 頂級專案 Apache Pulsar 2.6.1 版本
在正式分享 2.6.1 版本更新細節之前，冉小龍首先為我們分享了兩個相關 PIP 的內容。
一個是 PIP-47 中關於「基於時間來進行版本更新」的計劃。該 PIP 提出後，從 2.5.0 版本到目前即將釋出的 2.6.1 版本中，時間更短、釋出頻率更高成為最突出的特點。同時反饋週期快，基本是每三個月更新一個大版本。這樣使用者也可以大概瞭解版本的一個更新週期，增進了專案透明度。
另一個是 PIP-69 中計劃在 Go Client 中整合 schema 相關的功能和特性，更多詳情介紹可以參考下方：https://github.com/apache/pulsar/wiki/PIP-69%3A-Schema-design-for-Go-client
版本更新情況
此次 2.6.1 版本更新接收了來自社群的 112 次 commits，覆蓋 broker、Pulsar Functions、Go Function、Pulsar SQL、Schema、Java/CPP Client 等層面。同時截止目前 Apache Pulsar 專案已有 6400+ star、1500+ fork，以及即將超過 300 人的 contributor 數量。
接下來就簡單介紹一些 2.6.1 版本中的更新功能吧。
修復 Key_Shared 中 stick hash range 衝突的問題
Key_Shared 訂閱模式可以保證使用者在訂閱到某個 topic 時，可以指定 producer message key。訊息會根據指定 key 的不同，通過 hash range 有序傳送到不同的 consumer。
此 PR 主要是在 broker 端新增一個 check 機制，來避免 stick hash range 衝突。Stick hash range 的範圍是 0-65535，導致該錯誤的主要原因是因為在 broker 端，沒有對 stick hash range 中的 start 和 end 位置進行檢查。
正常情況下，是不允許 start 大於 end 的位置。在 2.6.1 中，我們加入了相應的 check 機制，來避免出現 range 衝突的問題。
在 Key_Shared 中對 payload 進行解壓縮
一般為了節約網路頻寬，在建立 producer 時，會根據不同場景選擇不同的壓縮型別。Consumer 端使用了 Key_Shared 訂閱模型來訂閱 topic，在訊息中，標註訊息的重要欄位可能是 payload 欄位。
在之前版本中是沒有針對在 Key_Shared 訂閱模式下對 payload 進行解壓縮的功能，此 PR 則是填補了這項功能。
修復在關閉 consumer 時的競態條件
根據上圖左邊圈出來的部分可以看出，message backlog 一直處於增加的狀態。Backlog 就是在訊息生產—消費過程中，沒有被 consumer 消費掉的訊息堆積，正常情況下，producer 生產訊息與 consumer 消費訊息的速率大致是一樣的。但是從上圖中的遞增狀態的 backlog 就表明了，訊息生產消費過程中出現了消費不均衡狀態。
此 PR 修復了當宕機重啟後，訊息生產消費錯開產生的競態條件，做法就是在中間加一些檢查機制。在 consumer 要開啟一個連線時，新增狀態檢查，如果當前 connection 的狀態為 closing 或者 closed 狀態時，我們不需要傳送 subscribe 的 command 到 broker 即可。
使用標準主機名作為 worker 的預設值
在 Java 8 和 Java 11 中，Get Hostname 返回的值是不一樣的。即 Java 8 中返回的是標準主機名，Java 11 中返回的是簡單主機名。此 PR 就是在 Java 11 中添加了可以獲取標準主機名的方法.
修復 2.6.0 引入的向後相容問題
在 pulsar 的整個版本迭代中，向後相容是一個很重要的保證。同時在是否合併 PR 的過程中也是一個十分重要的決定因素。
此 PR 中提到的向後相容問題是由於在 2.5.0 中支援了一個功能，允許多個 Pulsar cluster 去使用同一個 BookKeeper 的 cluster，所以在 2.5.0 的 broker 中，會響應帶有 BookKeeperMetadataServiceUri 的請求，但是 client 返回的結果卻是 null。
所以當 Function worker 和 broker 分開部署時，把 Function worker 和 broker 單獨從 2.5.0 更新到 2.6.0 時，會返回空指標異常。
修復的方式就是在初始化 Function worker 時，對 BookKeeperMetadataServiceUri 的 value 進行檢查，判斷它是否為 null。
優化 Pulsar Function 的加密配置
在之前的版本中，Function worker 與 TLS 相關的配置檔案/文件等介紹不太全面，此 PR 就是對此問題進行了同步優化。
主要是在 TLS transport encryption、Authentication Provider 和 Authorization Provider 上進行了部分修改，可以大致參考下圖。
更多關於授權和認證相關的內容，可以參考之前 TGIP-CN 的直播 ➡️ 深入瞭解 Pulsar 認證和授權機制。
在 pulsar-perf 中支援 tlsAllowInsecureConnectio
此 PR 在 ./bin/pulsar-perf produce命令中增加了允許不信任連線的功能，作用於 producer、consumer 和 reader 端。
處理在建立非永續性 cursor 時的錯誤
上圖中，當用戶在建立非永續性 cursor 失敗時，會返回一個 NPE 的 exception，這是因為當建立非永續性 cursor 失敗時，我們仍然會去建立一個 subscription instance 物件。
這將導致該 topic 的引用計數加一，當用戶想要刪除這個 topic 時，由於引用計數沒有被清零，所以即使使用 --force 強制去刪除，也刪除不掉，導致 topic 引用技術增加。
此 PR 就是在建立非永續性 cursor 失敗的時候，返回一個 failedFuture 物件，而不是去建立一個 subscription instance。
建立新 ledger 時引發 NPE 而導致生產者卡死的問題
由於無法解析網路地址，因此在建立 ledger 時會引發 NPE。如果在新增超時任務之前引發了 NPE，則超時機制不起作用。無法解析的網路地址在 Kubernetes 環境中很常見。當 bookie pod 或工作程式節點重新啟動時，可能會發生這種情況。
此 PR 的解決邏輯在於三個層面，即捕獲 NPE Exception、觸發超時任務時執行回撥策略、以及檢測 CreationLedger 的狀態。
完善 Window Function 相關的文件
在整個流處理資料中，經常需要以聚合方式進行資料收集和處理，通常以時間或者是資料數量為計量單位來進行，這種每個集合就屬於 window。
在 Pulsar Functions 中，window function 主要有三個重要概念。
- Trigger（觸發器）：決定當前 window 何時被計算/執行/刪除等操作。每個 window 都有相應觸發器去追蹤狀態。
- Evictor（過濾器）：當 window 被 trigger 觸發後，在 Window Function 處理之前會刪除視窗中不重要的元素。需要注意的是，Evictor 不是一個必需因素，可存在可不存在。
- Watermark（衡量線）：屬於資料本身的隱藏屬性，設定一些機制，保證在某些條件下必須觸發某些狀態。
增添 OAuth2 功能
OAuth2 屬於 2.6.1 版本中新增的一個大功能。當前 Pulsar 支援的 Authentication Providers 主要有以下幾種：
- TLS Authentication
- Athenz
- Kerbos
- JSON Web Token Authentication
整個 OAuth2 相當於授權框架/授權標準，它可以使用第三方應用程式/客戶端獲得 HTTP 服務上的賬戶資訊許可權訪問，通過使用者資訊委派給託管使用者資訊的一些伺服器進行工作。簡單來說就是為外部應用提供一個授權流程，更偏向於個人定製化特色，具體操作步驟如下圖：
目前支援 OAuth2 功能的主要有：
- Java Client（Client 版本在 2.6.1 及以上）
- CPP Client
- Go Client
- pulsar-admin
- pulsar-perf
- pulsar-client
- pulsarctl(CLI && admin API)
總結
此次直播主要在 Pulsar 版本更新細節中簡明扼要地分享了幾個重要細節，2.6.1 版本也將在未來幾天內正式釋出上線，敬請期待。更多直播細節可點選下方視訊回放觀看：https://v.qq.com/x/page/y3137om2z9z.html。