必须用namespace隔离租户，因只有tenant/namespace/topic三层路径才能触发配额、鉴权、策略继承等能力；topic前缀无法生效，client需显式传入完整路径如persistent://acme-prod/orders，且tenant和namespace须预先创建。
Pulsar 在 Golang 微服务中做多租户消息总线，核心不是“能不能”，而是「租户隔离粒度是否匹配业务」和「配置项是否真正生效」。直接上结论：必须用 namespace 隔离租户，且所有客户端连接、生产/消费逻辑都需显式携带 namespace 路径；否则所谓“多租户”只是逻辑分组，无实际资源或权限隔离。
为什么必须用 namespace 而不是 topic 前缀？
单纯靠 tenant1/order-topic 和 tenant2/order-topic 这种 topic 命名约定，无法触发 Pulsar 的租户级配额、鉴权、配额限制、策略继承等能力。只有通过 tenant/namespace/topic 三层路径（如 public/default/my-topic），Pulsar 才会将 default 视为一个独立的命名空间实体，支持：
• 单独设置消息 TTL、最大 backlog、生产速率限制
• 绑定独立的认证策略（如 JWT role mapping）
• 在 pulsar-admin namespaces 下执行细粒度操作
• 被 Kratos 或其他框架的中间件按 namespace 自动注入上下文
Go client 初始化时如何正确传入 tenant + namespace？
pulsar-client-go 不提供“租户级 client”抽象，所有隔离靠 topic URL 显式表达。错误写法是：Topic: "my-topic" —— 这默认走 public/default，且无法跨租户复用 client 实例。
正确写法必须带完整路径：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
producer, err := client.CreateProducer(pulsar.ProducerOptions{
Topic: "persistent://acme-prod/orders",
})
其中 acme-prod 是 tenant 名，orders 是 namespace 名（不是 topic）。注意：
• persistent:// 协议前缀不可省略，否则 client 会 fallback 到非持久化模式
• tenant 名必须已在 Pulsar 集群中通过 pulsar-admin tenants create acme-prod 创建
• namespace 必须提前创建：pulsar-admin namespaces create acme-prod/orders
• 若使用 TLS 或认证，ClientOptions 中的 Authentication 必须能解析出对应 tenant 的 role，否则 403
Kratos 服务里怎么让每个租户请求自动路由到对应 namespace？
不能靠 middleware 动态拼接 topic 字符串——topic 是 producer/consumer 初始化时静态绑定的。可行路径只有两条：
• 方案 A（推荐）：每个租户对应一个独立的 Kratos Service 实例，启动时从环境变量读取 PULSAR_TENANT 和 PULSAR_NAMESPACE，初始化专属 client 和 producer
• 方案 B（谨慎）：共享 client，但为每个租户缓存独立的 producer 实例，key 为 tenant/namespace，注意 producer 本身不轻量，别在 handler 内反复创建
• 绝对避免：在 RPC handler 里根据 ctx.Value("tenant_id") 拼接 topic 并 new producer —— 这会快速耗尽连接、触发 broker 端限流，且无法复用连接池
容易被忽略的 BookKeeper 存储层租户感知问题
BookKeeper 本身不感知 tenant 或 namespace，但它存储的 ledger 元数据由 Broker 注入，而 Broker 的 namespace 策略（如 retention、offload）直接影响 ledger 生命周期。常见坑：
• 开启 tiered storage（offload 到 S3）后，不同 namespace 的 offload 策略未单独配置，导致小租户消息被大租户策略误清理
• bookies 磁盘满时，Broker 默认按 ledger age 清理，若多个 tenant 共用同一 namespace，低频租户的 ledger 可能被优先删掉
• 使用 pulsarctl 查看 topic 详情时，msgRateIn 等指标是按 namespace 汇总，不是 tenant 级——监控告警必须按 namespace 设置，而非 tenant
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
