版本动态 | Apache Pulsar 2.9.3 发布

转载

ApachePulsar 2022-09-24 23:54:28

文章标签 java python mysql kafka 数据库 文章分类 运维

译者简介
许伟，西北工业大学，航天科工软件开发工程师，开源社区爱好者。本文由 StreamNative 组织翻译与校对。

Apache Pulsar 社区发布 2.9.3 版本！53 位贡献者提交了 200 余次变更，为社区的改进和错误修复贡献了一份力。感谢你们的所有贡献！

2.9.3 版本的亮点是引入了 30 多个事务功能相关的修复和改进。Pulsar 事务的早期用户记录了他们在生产环境中长期使用该功能的情况，并报告了在实际应用中的宝贵实践经验。Pulsar 社区得以优化相关功能特性。

本博客将介绍最重要的变更。有关功能增强和漏洞修复的完整列表，请查看 Pulsar 2.9.3 发行说明。欢迎大家下载并试用^[1] Pulsar 2.9.3。

显著的增强和错误修复

1.启用游标数据压缩以减少持久化游标数据大小。PR-14542^[2]

问题

游标数据由 ZooKeeper/Etcd 元数据存储管理。当数据大小增加时，可能会花费很多时间来拉取数据，同时 broker 最终可能会将大数据块写入 ZooKeeper/Etcd 元数据库。

解决方案

提供启用压缩机制能力，以减少游标数据大小和拉取时间。

2.减少了 metadataPositions 占用的内存，并避免了内存溢出。PR-15137^[3]

问题

MLPendingAckStore 中的 map metadataPositions 用于清除 PendingAck 中无用的数据，其中 key 是 PendingAck 中持久化的位置，value 是操作确认的最大位置。该参数判断最大订阅游标位置是否小于当前订阅游标的 markDeletePosition。如果最大位置更小，则日志游标将打上删除该位置的标记。它将导致以下两个主要问题：

• 通常情况下，该 map 存储所有事务的确认操作，这会对存储和 CPU 造成很大的浪费。
• 如果一个事务长时间没有提交，确认了它后面一条消息，该 map 不会被清除，最终会导致内存泄漏。

解决方案

按照一定的规则定期存储少量数据。有关更详细的实现，请参考 PIP-153。

3.在将事务 entry 追加到事务缓冲区之前检查 lowWaterMark。PR-15424^[4]

问题

当客户端使用先前提交的事务发送消息时，这些消息对消费者可见（非预期）。

解决方案

添加一个 map 将 Transaction Coordinator 的 lowWaterMark 存储在事务缓冲区中，并在将事务 entry 追加到事务缓冲区之前检查 lowWaterMark。因此，当使用无效事务发送消息时，客户端将收到 NotAllowedException。

4.修复了消费性能回归。PR-15162^[5]

问题

性能回归在 2.10.0、2.9.1 和 2.8.3 中引入。在使用 Java 客户端时，你可能会发现消息侦听器的性能显着下降。根本原因是每条消息在引入线程时会从外线程池切换到内线程池，最后再到外线程池。

解决方案

避免每条消息的线程切换，以提高消费吞吐量。

5.修复了主题创建的死锁问题。PR-15570^[6]

问题

该死锁问题发生在主题创建过程中，在删除它时会尝试从同一个线程重新获取相同的 StampedLock。这将导致该主题长时间停止服务，并最终导致数据去重或异地复制检查失败。解决方法是重新启动 broker。

6.优化了 broker 的内存使用。

问题

相比于使用 Boxing 类型，使用 Pulsar 的一些内部数据结构，比如 ConcurrentLongLongPairHashMap 和 ConcurrentLongPairHashMap，可以减少内存使用。但是，在早期版本中，即使删除了数据，也不支持对数据结构进行收缩，这在某些情况下会浪费一定的内存。

Pull requests