共计 3494 个字符，预计需要花费 9 分钟才能阅读完成。
在正式分享 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。
