![41db2f3e4bf6123dc57675c41c4490d1.png](https://i-blog.csdnimg.cn/blog_migrate/3d19c25e260be89d0438aa37ec6b71c3.jpeg)
在正式分享 2.6.1 版本更新细节之前,冉小龙首先为我们分享了两个相关 PIP 的内容。
一个是 PIP-47 中关于「基于时间来进行版本更新」的计划。该 PIP 提出后,从 2.5.0 版本到目前即将发布的 2.6.1 版本中,时间更短、发布频率更高成为最突出的特点。同时反馈周期快,基本是每三个月更新一个大版本。这样用户也可以大概了解版本的一个更新周期,增进了项目透明度。
另一个是 PIP-69 中计划在 Go Client 中集成 schema 相关的功能和特性,更多详情介绍可以参考下方:github.com/apache/puls…。
版本更新情况
此次 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。
![cbf6c075f85ec9b8f126202188a518ce.png](https://i-blog.csdnimg.cn/blog_migrate/1e55f12e9bfe4ff9415b292d84ca9aa5.jpeg)
此 PR 主要是在 broker 端添加一个 check 机制,来避免 stick hash range 冲突。Stick hash range 的范围是 0-65535,导致该错误的主要原因是因为在 broker 端,没有对 stick hash range 中的 start 和 end 位置进行检查。
正常情况下,是不允许 start 大于 end 的位置。在 2.6.1 中,我们加入了相应的 check 机制,来避免出现 range 冲突的问题。
![0686f42aae31590f371aea7048b2294d.png](https://i-blog.csdnimg.cn/blog_migrate/1420692ccf7bc15d0f7e0f5ae3eeda95.jpeg)
在 Key_Shared 中对 payload 进行解压缩
一般为了节约网络带宽,在创建 producer 时,会根据不同场景选择不同的压缩类型。Consumer 端使用了 Key_Shared 订阅模型来订阅 topic,在消息中,标注消息的重要字段可能是 payload 字段。
在之前版本中是没有针对在 Key_Shared 订阅模式下对 payload 进行解压缩的功能,此 PR 则是填补了这项功能。
![6c4d09daf9ce38c7a0b22f67bfb3cabd.png](https://i-blog.csdnimg.cn/blog_migrate/64db7517227b01531f66585d20eb2266.jpeg)
修复在关闭 consumer 时的竞态条件
![4b7bec8c965de723c3189ea50198977a.png](https://i-blog.csdnimg.cn/blog_migrate/e4da584ec515efc112a2bc1af7ac68ca.jpeg)
根据上图左边圈出来的部分可以看出,message backlog 一直处于增加的状态。Backlog 就是在消息生产—消费过程中,没有被 consumer 消费掉的消息堆积,正常情况下,producer 生产消息与 consumer 消费消息的速率大致是一样的。但是从上图中的递增状态的 backlog 就表明了,消息生产消费过程中出现了消费不均衡状态。
此 PR 修复了当宕机重启后,消息生产消费错开产生的竞态条件,做法就是在中间加一些检查机制。在 consumer 要打开一个连接时,添加状态检查,如果当前 connection 的状态为 closing 或者 closed 状态时,我们不需要发送 subscribe 的 command 到 broker 即可。
![21c95c2dc1ed2be3b73970823619555e.png](https://i-blog.csdnimg.cn/blog_migrate/b204ca6a941780192fe3cc9375168e15.jpeg)
使用标准主机名作为 worker 的默认值
![cf3ba39e0763a42e2914abc5266b9584.png](https://i-blog.csdnimg.cn/blog_migrate/e4d04e5db1b078ae57867678737b5858.jpeg)
在 Java 8 和 Java 11 中,Get Hostname
返回的值是不一样的。即 Java 8 中返回的是标准主机名,Java 11 中返回的是简单主机名。此 PR 就是在 Java 11 中添加了可以获取标准主机名的方法.
![b61a67edf14fa4f883e874820d3fdae4.png](https://i-blog.csdnimg.cn/blog_migrate/fccd19294702ec034ebe26846a043adb.jpeg)
修复 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 上进行了部分修改,可以大致参考下图。
![c100a4c9afe51a79bf3b0e8ae15d3bad.png](https://i-blog.csdnimg.cn/blog_migrate/3615a5d9bb5a74d3fe9828e1b89eaebd.jpeg)
更多关于授权和认证相关的内容,可以参考之前 TGIP-CN 的直播 ➡️ 深入了解 Pulsar 认证和授权机制。
在 pulsar-perf 中支持 tlsAllowInsecureConnectio
此 PR 在 ./bin/pulsar-perf produce
命令中增加了允许不信任连接的功能,作用于 producer、consumer 和 reader 端。
处理在创建非持久性 cursor 时的错误
![1a010d403f6fc358265f215fe7c8e515.png](https://i-blog.csdnimg.cn/blog_migrate/686d9110fac2f40c397ef381e6cf4b9e.jpeg)
上图中,当用户在创建非持久性 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。
![280a8248d971192b564bdc794a0e3f66.png](https://i-blog.csdnimg.cn/blog_migrate/3c1eff02b528d8325b200e99a968728f.png)
在 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 服务上的账户信息权限访问,通过用户信息委派给托管用户信息的一些服务器进行工作。简单来说就是为外部应用提供一个授权流程,更偏向于个人定制化特色,具体操作步骤如下图:
![3f0f5fcc183494b0bebaf67998d920f1.png](https://i-blog.csdnimg.cn/blog_migrate/5a930418694e2d90a404d730ac6448a3.jpeg)
目前支持 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 版本也将在未来几天内正式发布上线,敬请期待。更多直播细节可点击下方视频回放观看:v.qq.com/x/page/y313…。