解读

在国内一线互联网/AI公司面试中，这道题表面问“Topic 命名”，实则考察分布式消息系统极限水平扩展与Agent 身份寻址的综合设计能力。面试官期望候选人跳出“字符串怎么起名字”的表层思维，给出可横向扩展至百万级并发订阅的完整技术方案，并兼顾云原生成本、合规审计、灰度发布等国内落地诉求。核心矛盾是：Topic 数量不能随 Agent 线性膨胀（否则 Broker 元数据爆炸），又要保证每个 Agent 能精确、低延迟地收到属于自己的事件。

知识点

1. 国内主流消息中间件的横向扩展模型：RocketMQ 5.x 的 Broker 分片 + Logical Queue、Kafka 2.8 的 KRaft 元数据去 ZooKeeper、Pulsar 的 Bundle 拆分机制。
2. 百万级 Topic 元数据在内存中的索引压缩与冷热分级：RocketMQ 的 LmqOffsetStore、Pulsar 的 ManagedLedger 缓存分层。
3. Agent 身份编码需符合公安部《网络安全等级保护 2.0》对可审计唯一标识的要求，通常采用 “租户 + 业务域 + 实例指纹” 三段式。
4. 通配符订阅与Consumer Group 隔离的平衡：使用 分层 Topic 命名空间实现精准推送与广播双模式。
5. 云原生成本治理：Topic 数量直接影响IaaS 层 SLB 账单，需通过逻辑分区 + Tag 过滤减少物理 Topic 数。
6. 可观测性：在阿里云 ARMS或腾讯云 TDMQ 控制台中，Topic 命名必须支持正则级联监控，否则百万级指标会打爆 Prometheus 内存。

答案

采用**“逻辑 Topic + 动态 Tag + 一致性哈希分组”三级方案，可在百万 Agent 并发下把物理 Topic 总量控制在万级以内**，同时保持毫秒级过滤延迟。

1. 命名范式
   <租户>.<业务域>.<事件模型>.<版本>.<shardingKey>
   例：aiops.agent.v1.task.dispatch
   其中 shardingKey 仅取事件模型的哈希模 1024，用于RocketMQ Logical Queue做内部拆分，不会暴露给 Agent，避免用户层感知分区。

2. 身份映射
   每个 Agent 启动时向注册中心（Nacos 2.3 或 Polaris）写入“AgentID → 一致性哈希环槽位”映射，槽位数量固定为 8192。
   通过哈希环前置过滤，保证单个物理 Topic最多关联 8192 个订阅者，Broker 端过滤表内存占用 < 200 MB。

3. 动态 Tag
   在消息体内置128 bit 的 Agent 目标掩码（高 64 bit 为租户签名，低 64 bit 为AgentID 哈希）。
   Broker 利用 RocketMQ 的 SQL92 过滤或 Pulsar 的 Key_Shared 模式，在服务端布隆过滤器完成Tag 级精准推送，网络带宽节省 90%。

4. 元数据压缩
   对离线 Agent采用北极星（Polaris）心跳过期策略，30 秒无心跳即自动剔除订阅关系，并把对应过滤位图压缩为RoaringBitmap，内存再降 70%。

5. 合规审计
   Topic 命名中租户字段必须与阿里云 RAM 或腾讯云 CAM 的 UID 对齐，方便云审计（ActionTrail）直接关联到责任人，满足等保 2.0 对可追溯的要求。

6. 灰度发布
   在版本段使用**“v1.canary”后缀，Broker 通过 Tag 过滤把canary 流量限定在哈希环前 1% 槽位**，实现无损灰度。

通过以上设计，单集群可支持 10^6 Agent 并发订阅，物理 Topic 数 < 1 万，P99 消息延迟 < 30 ms，且符合国内云原生与合规双重要求。

拓展思考

1. 如果业务需要跨地域双活，Topic 命名如何与阿里云 DTS 或腾讯云 DTS-Message同步任务自动对齐，避免循环复制？
2. 当 Agent 规模从百万迈向千万级，一致性哈希环槽位是否需要动态扩容？如何做到零迁移成本？
3. 在信创环境（鲲鹏 + 麒麟）下，RocketMQ 的Logical Queue特性尚未合入开源主干，如何用DLedger 多副本手动实现逻辑分片？
4. 若未来引入大模型驱动的 Agent 自我复制，Topic 命名如何实时感知子 Agent 的裂变，并防止命名冲突导致的消息风暴？