消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载Apache Pulsar 2.0 是一次带来重大变更的主版本发布其中最直接影响日常使用的是property属性术语被tenant租户取代、Topic 全名中的 cluster 组件被移除以及随之而来的灵活shorthand命名规则。本文以 2.3.2 版本文档为主体结合仓库中 TopicName.java 等源码实现系统梳理这些变更的来龙去脉、新旧格式的兼容机制与底层解析逻辑帮助你在升级或新建集群时正确书写 Topic 名称、使用管理命令并理解旧集群数据为何无需迁移即可继续访问。Pulsar 2.0 的新特性与重大变更概览Pulsar 2.0 对平台做了若干大胆的bold改变除了引入新特性之外还包含可能显著影响日常使用的重大变更。变更概览如下表特性 / 变更说明Pulsar Functions面向 Pulsar 的轻量级计算lightweight compute能力作为 2.0 新特性加入Properties → Tenants统一术语property更名为tenant管理接口随之调整Topic 命名简化移除 Topic 全名中的 cluster 组件引入默认值驱动的灵活命名其它术语调整部分场景仍保留旧术语但已标记为 deprecated将在未来版本彻底移除其中 Pulsar Functions 允许直接在 Pulsar 集群内运行无状态、轻量级的处理逻辑如bin/pulsar-admin functions create命令本文不展开其细节重点聚焦命名体系的两项重大变更。重大变更一Properties 与 Tenants 的术语统一在 2.0 之前Pulsar 使用property属性概念作为多租户隔离的基本单位。从 2.0 开始property 术语被移除因为property 与 tenant 本质上就是同一个东西统一为tenant租户可以显著降低认知成本。管理接口的对应变化命令行管理接口是变化最直观的体现原先的pulsar-admin properties接口被pulsar-admin tenants接口取代。以 2.3.2 版本仓库中的 reference-pulsar-admin.md 为据tenants命令的用法与子命令如下$ pulsar-admin tenants subcommand支持的子命令包括list列出当前实例中已有的租户get获取某个租户的配置create创建新租户update更新租户配置delete删除租户例如查看 admin-api-tenants.md 中的创建示例$ pulsar-admin tenants create my-tenant对应的 REST API 为GET /admin/v2/tenants等/admin/v2路径下的接口Java 客户端则对应admin.tenants().getTenants()一类方法调用。源码中的术语残留从源码结构看虽然 2.0 已将术语统一为 tenant但在个别底层 API 中仍能看到旧时代痕迹。例如 TopicName.java 中的getCluster()方法被标注了Deprecated并在注释中说明其仅在旧命名格式下有意义旧格式persistent://tenant/cluster/namespace/topic包含 cluster 段而新格式persistent://tenant/namespace/topic没有。这印证了原文档部分场景仍使用旧术语、但已弃用并将在未来版本移除的说明——在代码层面cluster 字段在新命名下为null。重大变更二Topic 命名规则重构2.0 之前的完整 Topic 名格式在 2.0 之前所有Pulsar Topic 的名称都具有如下形式{persistent|non-persistent}://property/cluster/namespace/topic即四个组成部分Topic 类型持久化/非持久化、property、cluster、namespace 和 Topic 名。这种格式要求使用者时刻关心 Topic 属于哪个集群在跨集群部署和客户端连接时容易写错。2.0 的 Topic 命名变化Pulsar 2.0 对 Topic 命名做出了如下核心调整不再有 cluster 组件见下文移除 Cluster 组件property 更名为 tenant见上文引入灵活flexible命名系统很多场景下可以使用更短的名称/斜杠不允许出现在 Topic 名称中——因为斜杠是各段之间的分隔符TopicName.java 的解析逻辑正是按/切分来识别 tenant、namespace 与 localName 的Topic 名localName本身若含斜杠将破坏结构移除 Cluster 组件cluster 组件从 Topic 全名中移除后所有 Topic 名称的新形式为{persistent|non-persistent}://tenant/namespace/topic使用旧格式命名、已经存在的 Topic 将继续正常工作无需任何修改官方也没有改变这一兼容策略的计划。这意味着存量集群可以平滑过渡到 2.0无需迁移数据或改名。源码中的新旧格式共存逻辑新旧两种格式之所以能共存关键在 TopicName.java 的构造函数解析逻辑。其核心思路是若名称不含://视为短名short name按段数补全1 段补全为persistent://public/default/topic3 段补全为persistent://tenant/namespace/topic其余情况报IllegalArgumentException若含://对://之后的剩余部分按/切分3 段tenant/namespace/localName判定为新格式V2此时cluster null4 段tenant/cluster/namespace/localName判定为旧格式legacy保留 clusterisV2() 的实现即为return cluster null一目了然。TopicDomain 枚举同样只保留两种合法类型定义于 TopicDomain.javapublic enum TopicDomain { persistent(persistent), non_persistent(non-persistent); ... }客户端侧对非法名称的拦截也依赖这套解析例如 PulsarClientImpl.java 在创建 producer/consumer 前调用TopicName.isValid(topic)校验失败即抛异常从源头保证写入的 Topic 名必然符合上述规则。灵活FlexibleTopic 命名与默认值新命名系统之所以灵活是因为 2.0 引入了默认的 Topic 类型、默认租户与默认命名空间Topic 要素默认值topic 类型persistenttenantpublicnamespacedefault下表给出利用隐式默认值进行名称翻译的示例输入的 Topic 名翻译后的完整 Topic 名my-topicpersistent://public/default/my-topicmy-tenant/my-namespace/my-topicpersistent://my-tenant/my-namespace/my-topic这两个翻译结果与 TopicName.java 中短名补全逻辑的产出完全一致my-topic只有 1 段补上PUBLIC_TENANTpublic与DEFAULT_NAMESPACEdefaultmy-tenant/my-namespace/my-topic有 3 段直接补上persistent://前缀。仓库中大量示例也直接使用这种简写例如 client-libraries-java.md 中的.topic(my-topic)与 functions-overview.md 中--inputs persistent://public/default/sentences的完整写法并存。非持久化 Topic 的例外必须使用完整名称对于非持久化 Topicnon-persistent topics你必须继续写全整个 Topic 名称因为持久化 Topic 的默认值补全规则不适用于非持久化 Topic。因此你不能使用non-persistent://my-topic这样的简写而必须写成non-persistent://public/default/my-topic。这一约束同样能在源码中找到依据短名补全逻辑TopicName.java对不含://的名称一律按persistent类型补全TopicDomain.persistent是唯一的隐式默认一旦你显式写出non-persistent://前缀就必须同时给出 tenant 与 namespace 两段否则 3 段/1 段之外的切分结果会直接抛出IllegalArgumentException。关于非持久化 Topic 的更多背景可参考 concepts-messaging.md 中的说明其消息只存于内存、不落盘 BookKeeperbroker 故障或订阅者断开会导致在途消息丢失且其名称形式为non-persistent://tenant/namespace/topic因此使用前务必确认场景能容忍消息丢失。从源码看 Topic 名的规范化与内部表示理解了新旧格式后再深入一步TopicName对象不仅是字符串解析结果还是路由、持久化与查找的关键标识。名称归一化与缓存TopicName.java 使用 GuavaLoadingCache最大 10 万条、30 分钟无访问过期缓存解析结果所有TopicName.get(...)调用都经过缓存避免高频创建 producer/consumer 时反复解析字符串。构造函数L110-L185在完成段切分后会根据isV2()的结果把completeTopicName重写为标准形式V2 格式%s://%s/%s/%sdomain/tenant/namespace/localName旧格式%s://%s/%s/%s/%sdomain/tenant/cluster/namespace/localName也就是说即使你传入的是my-topic短名最终得到的TopicName.toString()也是完整的persistent://public/default/my-topic。不同场景下的序列化形式同一个TopicName对象在不同场景下会输出不同的路径形式getRestPath()L307-L318供管理 Web 服务使用的 REST 路径如persistent/my-tenant/my-namespace/my-topic注意://变成了/getLookupName()L348-L354用于 Topic 查找lookup如persistent/my-tenant/my-namespace/my-topicgetPersistenceNamingEncoding()L325-L336持久化资源的相对路径按tenant/namespace/domain/topic顺序组织将 domain 也作为路径段之一。无论哪种形式V2 与 legacy 的差别始终体现在是否包含 cluster 段上这与原文档描述的命名变化完全吻合。分区 Topic 的命名约定虽然原文档未展开但命名规则还隐含了分区 Topic 的约定PARTITIONED_TOPIC_SUFFIX 为-partition-第 N 个分区的名称为topic-partition-NL237-L243getPartitionedTopicName()则负责从分区名还原出基础 Topic 名。书写或解析名称时需留意这一后缀保留在 localName 中。迁移与实战建议综合原文档与仓库现状给出以下实操要点旧集群无需迁移采用persistent://tenant/cluster/namespace/topic旧格式的存量 Topic 会继续工作官方无变更计划可放心升级。新代码一律使用新格式新建 Topic 时推荐写全persistent://tenant/namespace/topic或non-persistent://...避免歧义仅在明确依赖默认值时可使用my-topic这类短名。非持久化 Topic 必须写全名non-persistent://public/default/my-topic不能使用non-persistent://my-topic简写。管理命令使用 tenants统一使用bin/pulsar-admin tenants create/list/get/update/delete不要再使用properties系列命令。注意名称合法性localName 中不要出现/否则会被解析器当作段分隔符并导致IllegalArgumentException客户端在创建 producer/consumer 前即会通过TopicName.isValid拦截非法名称。如果需要验证客户端 API 中短名与完整名的实际用法可在 client-libraries-java.md、client-libraries-cpp.md 等文档中查看.topic(my-topic)形式的示例需要确认租户管理命令的完整参数可继续阅读 admin-api-tenants.md 与 reference-pulsar-admin.md。小结Pulsar 2.0 通过property→tenant术语统一与 Topic 命名去 cluster 化显著降低了多租户与跨集群场景下的心智负担并用默认 tenant 默认 namespace 默认类型的灵活命名规则让日常使用更加简洁。仓库源码表明这些变更并非简单替换字符串而是内建在 TopicName 的解析与归一化逻辑之中新旧格式由段数自动识别、cluster段缺失即视为 V2、旧格式 Topic 兼容访问。理解这套规则无论迁移存量集群还是编写新客户端代码都能少踩名称不合法的坑。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 2.0 版本关键变更解析Tenant 命名体系与 Topic 名称重构Apache Pulsar 2.0 版本关键变更解析Tenant 命名体系与 Topic 名称重构 Pulsar 2.0 是 Apache Pulsar 历史消息队列后端流处理Apache Pulsar 2.0 升级指南Tenant 命名体系、Topic 名称简化与 Pulsar Functions 新特性Apache Pulsar 2.0 升级指南Tenant 命名体系、Topic 名称简化与 Pulsar Functions 新特性 本篇技术指南以 Puls消息队列后端流处理Apache Pulsar 2.0 版本指南Pulsar Functions 新特性与 Topic 命名体系变革Apache Pulsar 2.0 版本指南Pulsar Functions 新特性与 Topic 命名体系变革 Apache Pulsar 2.0 是 Pu消息队列后端流处理上一篇10分钟跑通采购比价引擎用FastGPT搭建自动比价的实战指南下一篇色彩表示系统完全指南Munsell色彩体系与十六进制编码解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apache Pulsar 2.0 命名体系变革解析：Property 到 Tenant 与 Topic 命名规则演进
消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载Apache Pulsar 2.0 是一次带来重大变更的主版本发布其中最直接影响日常使用的是property属性术语被tenant租户取代、Topic 全名中的 cluster 组件被移除以及随之而来的灵活shorthand命名规则。本文以 2.3.2 版本文档为主体结合仓库中 TopicName.java 等源码实现系统梳理这些变更的来龙去脉、新旧格式的兼容机制与底层解析逻辑帮助你在升级或新建集群时正确书写 Topic 名称、使用管理命令并理解旧集群数据为何无需迁移即可继续访问。Pulsar 2.0 的新特性与重大变更概览Pulsar 2.0 对平台做了若干大胆的bold改变除了引入新特性之外还包含可能显著影响日常使用的重大变更。变更概览如下表特性 / 变更说明Pulsar Functions面向 Pulsar 的轻量级计算lightweight compute能力作为 2.0 新特性加入Properties → Tenants统一术语property更名为tenant管理接口随之调整Topic 命名简化移除 Topic 全名中的 cluster 组件引入默认值驱动的灵活命名其它术语调整部分场景仍保留旧术语但已标记为 deprecated将在未来版本彻底移除其中 Pulsar Functions 允许直接在 Pulsar 集群内运行无状态、轻量级的处理逻辑如bin/pulsar-admin functions create命令本文不展开其细节重点聚焦命名体系的两项重大变更。重大变更一Properties 与 Tenants 的术语统一在 2.0 之前Pulsar 使用property属性概念作为多租户隔离的基本单位。从 2.0 开始property 术语被移除因为property 与 tenant 本质上就是同一个东西统一为tenant租户可以显著降低认知成本。管理接口的对应变化命令行管理接口是变化最直观的体现原先的pulsar-admin properties接口被pulsar-admin tenants接口取代。以 2.3.2 版本仓库中的 reference-pulsar-admin.md 为据tenants命令的用法与子命令如下$ pulsar-admin tenants subcommand支持的子命令包括list列出当前实例中已有的租户get获取某个租户的配置create创建新租户update更新租户配置delete删除租户例如查看 admin-api-tenants.md 中的创建示例$ pulsar-admin tenants create my-tenant对应的 REST API 为GET /admin/v2/tenants等/admin/v2路径下的接口Java 客户端则对应admin.tenants().getTenants()一类方法调用。源码中的术语残留从源码结构看虽然 2.0 已将术语统一为 tenant但在个别底层 API 中仍能看到旧时代痕迹。例如 TopicName.java 中的getCluster()方法被标注了Deprecated并在注释中说明其仅在旧命名格式下有意义旧格式persistent://tenant/cluster/namespace/topic包含 cluster 段而新格式persistent://tenant/namespace/topic没有。这印证了原文档部分场景仍使用旧术语、但已弃用并将在未来版本移除的说明——在代码层面cluster 字段在新命名下为null。重大变更二Topic 命名规则重构2.0 之前的完整 Topic 名格式在 2.0 之前所有Pulsar Topic 的名称都具有如下形式{persistent|non-persistent}://property/cluster/namespace/topic即四个组成部分Topic 类型持久化/非持久化、property、cluster、namespace 和 Topic 名。这种格式要求使用者时刻关心 Topic 属于哪个集群在跨集群部署和客户端连接时容易写错。2.0 的 Topic 命名变化Pulsar 2.0 对 Topic 命名做出了如下核心调整不再有 cluster 组件见下文移除 Cluster 组件property 更名为 tenant见上文引入灵活flexible命名系统很多场景下可以使用更短的名称/斜杠不允许出现在 Topic 名称中——因为斜杠是各段之间的分隔符TopicName.java 的解析逻辑正是按/切分来识别 tenant、namespace 与 localName 的Topic 名localName本身若含斜杠将破坏结构移除 Cluster 组件cluster 组件从 Topic 全名中移除后所有 Topic 名称的新形式为{persistent|non-persistent}://tenant/namespace/topic使用旧格式命名、已经存在的 Topic 将继续正常工作无需任何修改官方也没有改变这一兼容策略的计划。这意味着存量集群可以平滑过渡到 2.0无需迁移数据或改名。源码中的新旧格式共存逻辑新旧两种格式之所以能共存关键在 TopicName.java 的构造函数解析逻辑。其核心思路是若名称不含://视为短名short name按段数补全1 段补全为persistent://public/default/topic3 段补全为persistent://tenant/namespace/topic其余情况报IllegalArgumentException若含://对://之后的剩余部分按/切分3 段tenant/namespace/localName判定为新格式V2此时cluster null4 段tenant/cluster/namespace/localName判定为旧格式legacy保留 clusterisV2() 的实现即为return cluster null一目了然。TopicDomain 枚举同样只保留两种合法类型定义于 TopicDomain.javapublic enum TopicDomain { persistent(persistent), non_persistent(non-persistent); ... }客户端侧对非法名称的拦截也依赖这套解析例如 PulsarClientImpl.java 在创建 producer/consumer 前调用TopicName.isValid(topic)校验失败即抛异常从源头保证写入的 Topic 名必然符合上述规则。灵活FlexibleTopic 命名与默认值新命名系统之所以灵活是因为 2.0 引入了默认的 Topic 类型、默认租户与默认命名空间Topic 要素默认值topic 类型persistenttenantpublicnamespacedefault下表给出利用隐式默认值进行名称翻译的示例输入的 Topic 名翻译后的完整 Topic 名my-topicpersistent://public/default/my-topicmy-tenant/my-namespace/my-topicpersistent://my-tenant/my-namespace/my-topic这两个翻译结果与 TopicName.java 中短名补全逻辑的产出完全一致my-topic只有 1 段补上PUBLIC_TENANTpublic与DEFAULT_NAMESPACEdefaultmy-tenant/my-namespace/my-topic有 3 段直接补上persistent://前缀。仓库中大量示例也直接使用这种简写例如 client-libraries-java.md 中的.topic(my-topic)与 functions-overview.md 中--inputs persistent://public/default/sentences的完整写法并存。非持久化 Topic 的例外必须使用完整名称对于非持久化 Topicnon-persistent topics你必须继续写全整个 Topic 名称因为持久化 Topic 的默认值补全规则不适用于非持久化 Topic。因此你不能使用non-persistent://my-topic这样的简写而必须写成non-persistent://public/default/my-topic。这一约束同样能在源码中找到依据短名补全逻辑TopicName.java对不含://的名称一律按persistent类型补全TopicDomain.persistent是唯一的隐式默认一旦你显式写出non-persistent://前缀就必须同时给出 tenant 与 namespace 两段否则 3 段/1 段之外的切分结果会直接抛出IllegalArgumentException。关于非持久化 Topic 的更多背景可参考 concepts-messaging.md 中的说明其消息只存于内存、不落盘 BookKeeperbroker 故障或订阅者断开会导致在途消息丢失且其名称形式为non-persistent://tenant/namespace/topic因此使用前务必确认场景能容忍消息丢失。从源码看 Topic 名的规范化与内部表示理解了新旧格式后再深入一步TopicName对象不仅是字符串解析结果还是路由、持久化与查找的关键标识。名称归一化与缓存TopicName.java 使用 GuavaLoadingCache最大 10 万条、30 分钟无访问过期缓存解析结果所有TopicName.get(...)调用都经过缓存避免高频创建 producer/consumer 时反复解析字符串。构造函数L110-L185在完成段切分后会根据isV2()的结果把completeTopicName重写为标准形式V2 格式%s://%s/%s/%sdomain/tenant/namespace/localName旧格式%s://%s/%s/%s/%sdomain/tenant/cluster/namespace/localName也就是说即使你传入的是my-topic短名最终得到的TopicName.toString()也是完整的persistent://public/default/my-topic。不同场景下的序列化形式同一个TopicName对象在不同场景下会输出不同的路径形式getRestPath()L307-L318供管理 Web 服务使用的 REST 路径如persistent/my-tenant/my-namespace/my-topic注意://变成了/getLookupName()L348-L354用于 Topic 查找lookup如persistent/my-tenant/my-namespace/my-topicgetPersistenceNamingEncoding()L325-L336持久化资源的相对路径按tenant/namespace/domain/topic顺序组织将 domain 也作为路径段之一。无论哪种形式V2 与 legacy 的差别始终体现在是否包含 cluster 段上这与原文档描述的命名变化完全吻合。分区 Topic 的命名约定虽然原文档未展开但命名规则还隐含了分区 Topic 的约定PARTITIONED_TOPIC_SUFFIX 为-partition-第 N 个分区的名称为topic-partition-NL237-L243getPartitionedTopicName()则负责从分区名还原出基础 Topic 名。书写或解析名称时需留意这一后缀保留在 localName 中。迁移与实战建议综合原文档与仓库现状给出以下实操要点旧集群无需迁移采用persistent://tenant/cluster/namespace/topic旧格式的存量 Topic 会继续工作官方无变更计划可放心升级。新代码一律使用新格式新建 Topic 时推荐写全persistent://tenant/namespace/topic或non-persistent://...避免歧义仅在明确依赖默认值时可使用my-topic这类短名。非持久化 Topic 必须写全名non-persistent://public/default/my-topic不能使用non-persistent://my-topic简写。管理命令使用 tenants统一使用bin/pulsar-admin tenants create/list/get/update/delete不要再使用properties系列命令。注意名称合法性localName 中不要出现/否则会被解析器当作段分隔符并导致IllegalArgumentException客户端在创建 producer/consumer 前即会通过TopicName.isValid拦截非法名称。如果需要验证客户端 API 中短名与完整名的实际用法可在 client-libraries-java.md、client-libraries-cpp.md 等文档中查看.topic(my-topic)形式的示例需要确认租户管理命令的完整参数可继续阅读 admin-api-tenants.md 与 reference-pulsar-admin.md。小结Pulsar 2.0 通过property→tenant术语统一与 Topic 命名去 cluster 化显著降低了多租户与跨集群场景下的心智负担并用默认 tenant 默认 namespace 默认类型的灵活命名规则让日常使用更加简洁。仓库源码表明这些变更并非简单替换字符串而是内建在 TopicName 的解析与归一化逻辑之中新旧格式由段数自动识别、cluster段缺失即视为 V2、旧格式 Topic 兼容访问。理解这套规则无论迁移存量集群还是编写新客户端代码都能少踩名称不合法的坑。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 2.0 版本关键变更解析Tenant 命名体系与 Topic 名称重构Apache Pulsar 2.0 版本关键变更解析Tenant 命名体系与 Topic 名称重构 Pulsar 2.0 是 Apache Pulsar 历史消息队列后端流处理Apache Pulsar 2.0 升级指南Tenant 命名体系、Topic 名称简化与 Pulsar Functions 新特性Apache Pulsar 2.0 升级指南Tenant 命名体系、Topic 名称简化与 Pulsar Functions 新特性 本篇技术指南以 Puls消息队列后端流处理Apache Pulsar 2.0 版本指南Pulsar Functions 新特性与 Topic 命名体系变革Apache Pulsar 2.0 版本指南Pulsar Functions 新特性与 Topic 命名体系变革 Apache Pulsar 2.0 是 Pu消息队列后端流处理上一篇10分钟跑通采购比价引擎用FastGPT搭建自动比价的实战指南下一篇色彩表示系统完全指南Munsell色彩体系与十六进制编码解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
