Pulsar 2.6.0 到底更新了个啥?

最后都变了- 提交于 2021-01-14 06:52:37

这周我们请到了来自 StreamNative 的高级工程师——李鹏辉,为大家详细介绍一些关于 Pulsar 2.6.0 版本新特性。


首先回顾一些最近一周 Pulsar 的相关进展:


1. 新增 PIP-68:Exclusive producer
https://github.com/apache/pulsar/wiki/PIP-68%3A-Exclusive-Producer

2. Pulsar 2.6.1 版本也已在计划中,敬请期待!


接下来就一起看看关于 Pulsar 2.6.0 新特性吧!






PIP 相关



🖌 PIP-37:支持传输大消息体的消息


Pulsar 默认支持发送最大为 5 MB 的消息,如果超过,则 producer 不允许发送此消息。此 PIP 则通过将大消息体的消息拆分成多个 chunk,使其支持生产和消费大消息体的消息。

读取时则直接在 metadata 里获取「几个 chunk」目标信息,consumer 会根据获取到的目标信息,进行大消息组装。

目前,该功能仅对 non-shared subscription 有效,并对客户端有改动。如需使用该功能,你需要将 Pulsar 客户端升级至 2.6.0。使用该特性可以在生产端启用消息 trunking 机制。

更多此特性细节讲解,可参考视频回放 05:00-09:35 时间段。

🖌 PIP-39:新增 system topic,用于存储 namespace 更改事件

在 Pulsar 2.6.0 以前,Pulsar 只能设置 namespace 级策略,属于同一 namespace 的所有 topic 都遵循相同的 namespace 策略,但许多用户希望能设置 topic 级别策略。


另外,不使用 namespace 级策略的实现方式是因为更多的 Topic 策略会加重 ZooKeeper 负担,而 system topic 的设计初衷是希望将 topic 策略存储在 topic(而不是 ZooKeeper)中。

每个 namespace 下都有一个单独的 topic 做存储,只需开启此特性,即可自动创建 topic。如果去设置一个 topic retention,由 Pulsar admin 发起并调用 broker。该 broker 会把此事件写到对应的 namespace 下  _change_events  topic。

该 PIP 是实现 topic 级策略的第一步,基于此,未来可以实现更多相关功能。更多细节讲解可参考视频回放 09:35 - 22:00 时间段。

🖌 PIP-54:支持在 batch index 级确认消息

在 Pulsar 2.6.0 以前,broker 仅在 batch message 级追踪消息确认状态。如果部分批量消息中已被确认,消息重新发送给 consumer 时仍会收到“部分批量消息已确认”的信息。

比如,接收到的 batch 中有多个消息。在下图中,将消息发送给 consumer-1 去消费。如果其中一条消息消费失败,这条消息会再次被发送进行消费。此时再次发送时,就会导致(0,2)进行了重复消费。


该 PIP 支持在 batch index 级确认消息。因此,它支持跟踪每个批处理索引的 ack 状态,以避免向用户发送已经处理过的消息。默认情况下,该功能未开启。如需开启,你可以在 `broker.conf` 文件中设置。

这种方法需要 client 和服务器端进行合作。当 broker 分派消息时,它将携带已 ack 的 batch index。同时 client 端则会过滤掉已 ack 的 batch index。


Client 需要向 broker 发送 batch index 的 ack 信息,以便 broker 能够保持 batch index 的 ack状态。

更多关于此特性的细节讲解,可以参考视频回放 24:30—32:30 时间段。

🖌 PIP-58:支持 consumer 设置自定义消息重发延时

对于许多在线业务系统而言,业务逻辑处理时常出现各种异常,因此需要重新消费消息,且用户希望可以自定义设置延迟时间。在 Pulsar 2.6.0 之前,当客户端发送 nack 至 broker,Pulsar 会立刻重发消息。从 Pulsar 2.6.0 开始,则可以为每条消息设置重发延时。

🖌 PIP-61:支持多个 advertised address

目前,代理只支持在代理配置文件(broker.conf)中配置的一个 advertised address。但是,当部署在生产 Pulsar 集群中时,可能需要为代理公开多个已公开的地址。该 PIP 允许 broker 暴露多个 advertised listeners,并支持内网和外网流量分离。


这种方法引入了两个新的配置, `advertisedListeners` `internalListenerName`

`advertisedListeners` 用于指定多个 advertised listeners,而 `internalListenerName` 用于指定代理使用的内部服务URL。

在设置了 `advertisedListeners` 之后,clients 可以选择其中一个 listeners 作为服务URL来创建到代理的连接,只要网络是可访问的。

但是,如果 client 在某个 topic 上创建生产者或消费者,则 client 必须向 broker 发送查找请求以获取 owner broker,然后连接于此以发布消息或使用消息。

用户可以在 `broker.conf` 文件中指定多个 advertised listeners。也可以为客户端指定 listener 名称。

更多关于此特性细节讲解,可以参考视频回放 36:00-44:20 时间段。




Key_Shared 相关




✏️ 在 Key_Shared 订阅中增加一致性 hashing 分配

在 Pulsar 2.6.0 之前,Key_Shared 订阅是通过使用 hash range 自动分裂来实现,该方法基于在新 consumer 加入或离开时分裂现有已分配的 hash range。


Pulsar 2.6.0 为 Key_Shared 订阅新增一致性 hash 分配。你可以在 `broker.conf` 文件中启用该功能。自动分裂(auto split)方法仍默认开启。

✏️ 解决了新增 consumer 时,Key_Shared dispatcher 出现的乱序问题

该 PR 对 Key_Shared 订阅功能非常重要。在 Pulsar 2.6.0 之前,当新增 consumer(c2)进入且现有 consumer(c1)退出时,顺序在 Key_Shared dispatcher 中不能保证。这是因为之前分配至 c1 的消息和 key 可能路由至 c2,这可能导致 Key_Shared 订阅中同一个 key 的消息顺序分发保证失效。


为了保证消息按序分配,在之前的消息被确认之前,新增 consumer 会变成“暂停”状态。如果你仍想使用松散的顺序分发保证,可以在 consumer 端进行以下设置。

pulsarClient.newConsumer().keySharedPolicy(KeySharedPolicy.autoSplitHashRange()。setAllowOutOfOrderDelivery(true)).subscribe();

以上关于 Key-shared 相关特性细节介绍,可以参考视频回放 44:30-53:00 时间段。

✏️ 支持设置 `maxLedgerRolloverTimeMinutes` 参数,用于触发 ledger 切换

该特性实现了一个监测线程,用于检查当前 topic ledger 是否满足 `managedLedgerMaxLedgerRolloverTimeMinutes` 条件并触发 ledger 切换使配置生效。


如果触发 ledger 切换,你可以关闭当前 ledger 并释放当前 ledger 的存储空间。对于不常使用的 topic,当前 ledger 数据可能失效,且当前切换操作仅适用于新增 entry 时。很显然,这会浪费磁盘空间。


监测线程在固定间隔时间检查 ledger 是否需要切换。用户可以通过 `managedLedgerMaxLedgerRolloverTimeMinutes` 设置该时间间隔。

更多关于此特性细节讲解,可以参考回放视频 53:05-57:00 时间段。

📌 支持 entry 检查延迟

在 Pulsar 2.6.0 之前,新增 entry 检查延迟是 10 ms(且用户无法设置该值)。现在,对于消费延迟敏感的场景,你可以在 `broker.conf` 文件中将新增 entry 检查延迟设置成更小值(可能降低消费吞吐)或 0。

更多关于 Pulsar SQL、Pulsar Client 等功能特性,可以直接查看 Apache Pulsar 2.6.0 重磅发布,新特性独家解读

或者参考回放视频 59:50-68:00 时间段。





Q&A



Q:最后一点优化,会不会使得收消息越来越慢?
A:其实分发逻辑主要根据 batch 里的消息数量决定,不受 consumer 性能修改等操作影响。

Q:当消费者性能下降时候,batch message 平均值越来越小?
A:Batch message 不是由 consumer 决定的,是由 producer 决定的。发送消息时已确定,所以与 consumer 消费快与慢没有太大关系。




总结



本次直播主要对 Pulsar 2.6.0 版本的一些新特性进行了细致的解读。相比于满是文字的版本 release,直播可能会更加丰富形象一些。如果大家想看更细节的讲解,记得查看下方视频回放


本周的 TGIP-CN 将有 Apache 龙为大家带来《Pulsar Functions Deep Dive》相关内容讲解,搭配之前 Pulsar Summit 内容进行个人扩展,点击「阅读原文」即可进行报名,敬请期待!

本文分享自微信公众号 - StreamNative(StreamNative)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!