特性预览：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 主要有以下几种：