Apache Pulsar 发布 2.3.1 版本_Apache Pulsar

 

Apache Pulsar 发布 2.3.1 版本

 

Apache Pulsar 在 4月 12 日正式发布了2.3.1 版本!2.3.1 版本继续丰富和完善了 Apache Pulsar 作为一个云原生流数据平台的能力。

 

2.3.1 修复和改进了众多用户在使用 2.3.0 版本中反馈的问题,这些修复覆盖了从消息存储核心,多语言客户端,到 Pulsar Functions 等多方面。在这篇文章中,我们将会为大家详细解读 2.3.1 中修复和改进的特性。这其中包括:

在核心存储方面,支持自动生成 schema,支持用户使用预定义的 Schema Definition。Broker 方面增加 Jetty 线程,降低死锁发生率;同时增加了消费者许可权限。在安全方面,完善了跳转请求的认证功能。

在多语言客户端,优化了 Java,C++,Go 和 Python 上批量发送、读取信息,同时支持在创建消费者时指定具体的初始消费位置。

在 Pulsar Functions 方面,修复了提交功能,可以通过 URL 上传整个文件。

1

CORE

Schema

在 2.3.1之前,Schema Definition 是通过 POJO 的方式来生成,这种方式需要预先知道 POJO 的定义,但有一些场景我们并不能提前获取到 POJO 的定义,比如:CDC(Change Data Capture)的场景。如果没有办法预定义 POJO,也就没有办法获取到相应的 Schema Defition。在 2.3.1 版本中,Pulsar 引入基于 AVRO Schema 的 SchemaBuilder,让用户可以通过编程的方式定义自己的 Schema。该功能目前只支持基础类型字段,其它类型将在后续版本中支持。

 

除此之外,2.3.1 版本支持用户在 JSON 和 AVRO 上使用预定义的 Schema Definition。目前 Schema Definition 是直接根据 POJO 生成的,直接根据 POJO 生成的 Schema Definition 容易造成混淆。基于此,我们提供了相应的方式,来支持用户使用预定义的 Schema Definition ,来避免混淆的发生。

Broker

该版本中把 Jetty 默认的线程数从 4 条增加到了 8 条,降低了死锁发生的可能性。Pulsar 中的管理大量使用了基于 Jetty 的 Rest API,Jetty 中的线程数太少会造成 HTTP 调用的死锁。比如在创建提交 Pulsar Functions、运行 pulsar-admin 命令时,可能会遇到死锁的情况。改进后,发生死锁的几率大大降低。

此外,Pulsar 修复了在处理消息 dedup 和 delay ack 中存在的 Permit 不一致的 Bug。该 Bug 会导致造消费者因为不能从 Broker 获取 Permits 而无法消费消息。

Security

该版本改用了 Jersey 基于 Java NIO 的 JDK provider 来替换 `HttpUrlconnectionProvider`,优化了跳转请求的认证功能。在 Jersey 的 client 中默认使用 JDK 中标准的 `HttpUrlConnection`,在 JDK8(比如 1.8.0_181)中,这个类在处理 HTTP 跳转请求时,header 里面的 `Authorization` 部分会丢失,造成认证失败。

 

2

CLIENTS

Java

修复了从分区读取数据的问题:从分区主题中读取数据时,由于没有发送 permits 导致消费者无法消费。

在 Topic recovery 后,把游标设置为非活跃,用以减少对垃圾搜集器的影响。

允许批量发送 5 MB 以上的信息 。无论是发送单条消息,还是批量发送消息,只要压缩后的大小控制在 5MB 内,都可以发送成功。

修复 Pulsar Reader 读取批量信息(batchMessage)的逻辑,能够正确及时判断是否有消息。在之前的版本中,Reader 在处理 batchMessage 时,由于 `hasMessageAvailable` 处理的不恰当,会造成错误的判断,导致有消息,reader 却不能获取消息的问题。

C++

允许批量发送 5 MB 以上的信息 。无论是发送单条消息,还是批量发送消息,只要压缩后的大小控制在 5MB 内,都可以发送成功。

优化 C++ 批量信息确认逻辑,减少系统资源消耗。

Go

修复 Reader.HasNext() 函数,当没有消息需要读取时,`Reader.HasNext()` 不再返回 `true`。之前的版本,在 reader 中,当没有更多的消息要读取时,`Reader.HasNext()` 将始终返回 true。这个问题是因为 C++ 的  `Consumer::hasMessageAvailable()` 和消息的监听器是组合使用的,只有当监听器被触发后,`lastDequedMessage` 才会被更新,所以当监听器去检查 `hasMessageAvailable()` 时,永远只有一条消息。因为 Go client 的 `Reader.HasNext()` 是基于此封装的,所以也会受到影响。

Python

在 Python 上添加 `producer.flush()` 函数,优化 batch 功能。刷新客户端中缓冲的所有消息,并等待所有消息成功保留,优化 batch 功能。使用 batch 时,如果还没有达到 batch 的数量,但想将 batch 现有的数据持久化到 BookKeeper ,可以调用 flush 以触发持久化的功能。

在 Python client 中,支持用户在创建 consumer 时指定具体的初始消费位置,有如下两个选项可供选择:Earliest 和 Latest(默认值)。

 

3

FUNCTION

修复函数提交功能。之前存在的问题是只能部分上传 Functions 文件的问题,修复之后可以上传整个的包文件。

 

下载链接

 

Pulsar 2.3.1 的下载链接:

https://pulsar.incubator.apache.org/en/download/

Pulsar的项目链接:

https://pulsar.incubator.apache.org/

Pulsar的Github代码库:

https://github.com/apache/incubator-pulsar

Pulsar的Slack Channel:

https://apache-pulsar.herokuapp.com/

Pulsar的邮件列表:

https://pulsar.incubator.apache.org/contact/

Apache Pulsar 发布 2.3.1 版本_Apache Pulsar _02