消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载本篇技术指南围绕 Apache Pulsar 的多租户multi-tenancy管理能力展开聚焦 Tenant租户的创建、查询、更新、删除四大操作覆盖pulsar-admin命令行、REST Admin API 与 Java Admin API 三种管理方式。读者学完后将掌握 Tenant 在 Pulsar 中的定位、其两个核心可配置维度Admin Roles 与 Allowed Clusters的语义以及如何用三种工具安全地完成租户全生命周期管理。Tenant 在 Pulsar 多租户体系中的定位Pulsar 的资源模型从上到下依次为Tenant → Namespace → Topic。Tenant 是最顶层的资源隔离单元用于在多租户场景下按部门、项目或业务线划分数据归属Namespaces 则是 Tenant 内部的二级隔离单元如区分生产/测试环境。这一层级关系在官方术语文档 reference-terminology.md 中有明确定义也体现在命名约定上——一个完整主题名的格式为persistent://tenant/namespace/topic例如测试中使用的persistent://prop_xyz/my-namespace/my-topic。与 Namespace 一样Tenant 可以通过 Admin API 进行管理。每个 Tenant 目前有两个可配置维度Admin roles管理员角色允许管理该 Tenant 及其下 Namespace/Topic 的认证主体auth principal列表通常表现为一组角色标识Allowed clusters允许的集群该 Tenant 可用的 Pulsar 集群白名单用于限制数据只能落在指定集群上。从数据模型看这两个维度被封装在TenantInfo数据结构中。接口定义位于 pulsar-client-admin-api/src/main/java/org/apache/pulsar/common/policies/data/TenantInfo.java仅暴露getAdminRoles()与getAllowedClusters()两个读取方法其默认实现 pulsar-common/src/main/java/org/apache/pulsar/common/policies/data/TenantInfoImpl.java 通过Data、AllArgsConstructor等注解提供了完整的构造与序列化支持并内置 Builder 便于 Java 侧链式组装。环境与前置条件本文示例面向 Pulsar 2.3.2 版本管理操作需要具备以下前提可访问的 Pulsar 集群包括 standalone 模式具备 Pulsarsuper-user 权限。从源码看Tenant 的创建、更新、删除及查询在服务端都经过validateSuperUserAccess()校验见 pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/TenantsBase.java已配置好pulsar-admin客户端conf/client.conf或 PulsarAdmin Java 客户端。说明官方文档指出本文仅展示最常用的操作pulsar-admin、REST API 与 Java Admin API 的完整参数、响应与用法说明请以 Pulsar 官方工具文档、REST API 文档与 Java Admin API 文档为准本文聚焦于仓库当前版本的实际实现与常用操作。用 pulsar-admin 管理 Tenantpulsar-admin是 Pulsar 内置的管理 CLI其 Tenant 子命令定义在 pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdTenants.java共注册了 5 个子命令list、get、create、update、delete。列出全部 Tenanttenants list列出当前 Pulsar 实例Instance中关联的所有 Tenant$ pulsar-admin tenants list my-tenant-1 my-tenant-2从实现看该命令底层调用admin.tenants().getTenants()见CmdTenants中的List命令服务端在 TenantsBase.java 中经validateSuperUserAccess()校验后从元数据存储读取 Tenant 列表并按字典序排序返回。创建 Tenanttenants create创建新 Tenant$ pulsar-admin tenants create my-tenant创建时可通过-r/--admin-roles参数指定管理员角色多个角色用逗号分隔$ pulsar-admin tenants create my-tenant \ --admin-roles role1,role2,role3 $ pulsar-admin tenants create my-tenant \ -r role1create子命令还支持-c/--allowed-clusters参数限定允许的集群。该参数在 CmdTenants.java 中被声明为可选若省略或为空则自动默认使用当前集群中的全部集群getAdmin().clusters().getClusters()adminRoles未指定时默认为空列表。需要注意尽管 CLI 允许省略allowedClusters服务端validateClusters()校验见 TenantsBase.java要求 TenantInfo 中的集群列表不能为空且每个集群必须真实存在或为全局集群global否则会以 HTTP 412Precondition Failed拒绝。查看 Tenant 配置tenants get随时查看某个已有 Tenant 的配置$ pulsar-admin tenants get my-tenant { adminRoles: [ admin1, admin2 ], allowedClusters: [ cl1, cl2 ] }返回的 JSON 即TenantInfo的两个字段adminRoles管理员角色集合与allowedClusters可用集群集合。更新 Tenant 配置tenants update修改已有 Tenant 的配置$ pulsar-admin tenants update my-tenant与create不同update子命令的语义是增量修改从 CmdTenants.java 的实现看若未传-r/--admin-roles则沿用当前 Tenant 已配置的角色集合若未传-c/--allowed-clusters则沿用当前集群集合。因此执行update而不带任何参数时等价于保持现状。服务端在 TenantsBase.java 会先校验 Tenant 是否存在、集群是否合法再通过canUpdateCluster确认新集群集合是否可切换例如确保现有 Namespace 所在集群仍被允许。删除 Tenanttenants delete从 Pulsar 实例中删除 Tenant$ pulsar-admin tenants delete my-tenant删除子命令还提供-f/--force参数强制删除该 Tenant 及其下所有 Namespaces。服务端逻辑在 TenantsBase.java非强制模式先校验 Tenant 下没有活跃 NamespacehasActiveNamespace再依次清理持久化主题、Namespace、分区主题、本地策略与负载均衡 bundle 数据强制模式先要求 broker 配置forceDeleteTenantAllowedtrue默认false否则返回 HTTP 405随后并行强制删除其下所有 Namespaces再走常规删除流程。用 REST Admin API 管理 TenantREST Admin API 是pulsar-admin与 Java Admin API 的底层通信协议每个操作都对应一个 HTTP 端点。服务端实现位于 pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/TenantsBase.java各端点映射如下操作方法路径说明列出 TenantGET/admin/v2/tenants返回全部 Tenant 名称列表查看 Tenant 配置GET/admin/v2/tenants/{tenant}返回该 Tenant 的TenantInfoJSON创建 TenantPUT/admin/v2/tenants/{tenant}请求体为TenantInfoTenant 已存在时返回 409名称非法或集群非法时返回 412更新 Tenant 配置POST/admin/v2/tenants/{tenant}请求体为新的TenantInfoTenant 不存在时返回 404删除 TenantDELETE/admin/v2/tenants/{tenant}?force{false/true}存在活跃 Namespace 时返回 409强制删除被禁用时返回 405以创建为例示例请求PUT /admin/v2/tenants/my-tenant Content-Type: application/json { adminRoles: [admin1, admin2], allowedClusters: [cl1, cl2] }注意文档中创建端点写作PUT /admin/v2/tenants/:tenant、查询端点写作GET /admin/v2/tenants/:cluster这里的:tenant/:cluster均指路径参数——查询、删除场景下实际传入的是 Tenant 名称。用 Java Admin API 管理 TenantJava Admin API 通过PulsarAdmin对象暴露tenants()句柄其接口定义在 pulsar-client-admin-api/src/main/java/org/apache/pulsar/client/admin/Tenants.java覆盖同步与异步Async后缀两种调用方式。列出 Tenantadmin.tenants().getTenants();返回ListString即全部 Tenant 名称异步版本为getTenantsAsync()返回CompletableFutureListString。创建 Tenantadmin.tenants().createTenant(tenantName, tenantInfo);tenantInfo需要构造TenantInfo对象推荐使用TenantInfo.builder()定义于 TenantInfo.javaTenantInfo tenantInfo TenantInfo.builder() .adminRoles(Collections.singleton(admin1)) .allowedClusters(Collections.singleton(cl1)) .build(); admin.tenants().createTenant(my-tenant, tenantInfo);查看 Tenant 配置admin.tenants().getTenantInfo(tenantName);返回TenantInfo可通过getAdminRoles()/getAllowedClusters()读取角色与集群集合Tenant 不存在时抛出NotFoundException。更新 Tenant 配置admin.tenants().updateTenant(tenantName, tenantInfo);更新是全量替换语义传入的TenantInfo会整体覆盖原有配置。与 CLI 的“未传即保留”不同Java 侧需要自己先getTenantInfo再合并字段后提交或直接构造完整的新配置。删除 Tenantadmin.tenants().deleteTenant(tenantName); // 常规删除 admin.tenants().deleteTenant(tenantName, true); // 强制删除需 broker 开启 forceDeleteTenantAllowed按 Tenants.java 的文档注释删除会连带移除该 Tenant 下所有 Namespaces 与 Topics若 Tenant 仍有活跃 Namespaces抛出ConflictException每个方法都有对应的Async异步变体。底层机制与关键配置Tenant 名称合法性校验创建 Tenant 时服务端通过NamedEntity.checkName(tenant)校验名称规则定义在 pulsar-common/src/main/java/org/apache/pulsar/common/naming/NamedEntity.javapublic static final Pattern NAMED_ENTITY_PATTERN Pattern.compile(^[-:.\\w]*$);即 Tenant与 Namespace、Cluster、Topic名称允许的字符为字母数字、下划线以及-、、:、.等特殊符号。仓库测试 AdminApi2Test.java 分别验证了含下划线的名称prop_xyz可正常创建并使用而含空格prop xyz或propxyz的名称会立即以 412 状态码失败。集群白名单校验创建/更新时validateClusters()会做两层校验见 TenantsBase.java集群列表不能为空含空白字符串列表中的每个集群必须已存在于集群资源中或是全局集群global。对应测试 AdminApi2Test.java 验证了向不存在的集群cluster-non-existing创建或更新 Tenant 均会以 412 失败。影响 Tenant 管理的 Broker 配置项以下配置定义于 pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java均支持动态更新配置项默认值作用forceDeleteTenantAllowedfalse是否允许强制删除 Tenant即连带删除其下所有 Namespaces为false时强制删除返回 405。对应conf/standalone.conf中的forceDeleteTenantAllowedfalse见 standalone.confmaxTenants0每个 Pulsar 集群最多可创建的 Tenant 数0表示不限制。服务端在创建时检查见 TenantsBase.java注释明确指出该阈值并非精确控制并发场景下可能被略微超出完整生命周期示例结合三种管理方式一个典型的 Tenant 生命周期如下以pulsar-admin为例# 1. 查看当前集群 $ pulsar-admin clusters list # 2. 创建 Tenant指定管理员角色与可用集群 $ pulsar-admin tenants create my-tenant \ --admin-roles admin1,admin2 \ --allowed-clusters cl1,cl2 # 3. 验证配置 $ pulsar-admin tenants get my-tenant # 4. 调整管理员角色不改变集群集合 $ pulsar-admin tenants update my-tenant \ --admin-roles admin1,admin3 # 5. 确认结果 $ pulsar-admin tenants get my-tenant # 6. 在 Tenant 下创建 Namespace 与 Topic 后删除租户 # —— 先清理 Namespace或使用 -f 强制删除 $ pulsar-admin tenants delete my-tenant对应地仓库集成测试 AdminApi2Test.java 完整演示了创建 Tenant → 创建 Namespace → 创建分区 Topic → 清理 Topic/Namespace → 删除 Tenant → 校验元数据路径全部清除的删除流程可作为端到端验证的参考非空 Tenant 无法直接删除必须先删除其下所有 Namespace含其中的 Topic否则删除操作会以 409 失败。小结Tenant 是 Pulsar 多租户体系的第一道隔离边界其管理聚焦于adminRoles与allowedClusters两个维度。无论使用pulsar-adminCLI、REST Admin API 还是 Java Admin API底层都汇流到 TenantsBase.java 同一套服务端校验与元数据读写逻辑理解名称规则、集群白名单、forceDeleteTenantAllowed与maxTenants等约束即可在生产环境中安全、规范地规划多租户资源。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 租户Tenant管理实战指南pulsar-admin、REST API 与 Java Admin APIApache Pulsar 租户Tenant管理实战指南pulsar admin、REST API 与 Java Admin API 导读 租户Tena消息队列后端流处理Apache Pulsar 租户Tenant管理实战指南pulsar-admin CLI、REST API 与 Java Admin API 全解Apache Pulsar 租户Tenant管理实战指南pulsar admin CLI、REST API 与 Java Admin API 全解 本篇技消息队列后端流处理Apache Pulsar 租户Tenant管理实战指南pulsar-admin CLI、REST API 与 Java Admin API 全解析Apache Pulsar 租户Tenant管理实战指南pulsar admin CLI、REST API 与 Java Admin API 全解析 Ap消息队列后端流处理上一篇Krell资产与依赖管理轻松处理React Native项目资源下一篇DLSS Swapper免费升级或回退游戏内 DLSS/FSR/XeSS DLL 的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考