1. 核心概念：从“物理订阅”升级为“逻辑订阅”
Dynamic Kafka Source 不是直接让你写topics = ["a", "b"]，而是让你订阅一个或多个stream id：
- stream id：逻辑流名称，比如
"input-stream" - KafkaMetadataService：把 stream id 映射成「cluster + topics + properties」
这样，当 stream id 的映射发生变化（增加 topic / 切换 cluster），Source 就能在运行中自动“换订阅对象”。
2. 快速上手：构建 DynamicKafkaSource
下面示例从最早 offset 开始消费"input-stream"，只反序列化 value 为字符串，并通过自定义MyKafkaMetadataService解析真实集群与 topic：
DynamicKafkaSource<String>source=DynamicKafkaSource.<String>builder().setKafkaMetadataService(newMyKafkaMetadataService()).setStreamIds(Collections.singleton("input-stream")).setStartingOffsets(OffsetsInitializer.earliest()).setDeserializer(KafkaRecordDeserializationSchema.valueOnly(StringDeserializer.class)).setProperties(properties).build();env.fromSource(source,WatermarkStrategy.noWatermarks(),"Dynamic Kafka Source");构建时的关键必填项：
setKafkaMetadataService(...)：你的“元数据真相来源”setStreamIds(...)或setStreamPattern(...)：订阅哪些逻辑流setDeserializer(...)：消息反序列化（与 KafkaSource 一致）
3. 两种订阅方式：按集合 or 按正则
- 显式指定 stream id 集合
DynamicKafkaSource.builder().setStreamIds(Set.of("stream-a","stream-b"));- 使用正则订阅匹配的 stream id（适合多租户/多业务线命名规范）
DynamicKafkaSource.builder().setStreamPattern(Pattern.of("stream.*"));这里的正则是匹配“stream id”，而不是直接匹配 topic 名称。topic 的映射仍然由 KafkaMetadataService 决定。
4. KafkaMetadataService：动态能力的发动机
KafkaMetadataService 的作用是：把逻辑流解析成物理订阅信息。典型实现方式：
- 对接公司内部的 Kafka 管控平台/元数据中心（推荐）
- 没有平台时，用内存版/配置文件版先跑通（文档里也提到测试里有 in-memory 实现）
Dynamic 的关键机制：
- Source 会周期性轮询KafkaMetadataService
- 发现映射变化后，Enumerator 会发事件给 Reader，触发“订阅重协调”
- 集群被移除时，会被视为 non-active，Reader 会停止读取该集群
5. 重要配置：发现周期与失败阈值
DynamicKafkaSourceOptions 里有两个非常关键的开关（通过 builder properties 传入）：
stream-metadata-discovery-interval-ms- 轮询元数据变化的间隔（毫秒）
- <=0 会禁用动态发现（就退化成“启动时确定一次”）
stream-metadata-discovery-failure-threshold- 连续失败多少次后，抛出异常触发 JobManager 失败并全局 failover
- 默认 1：至少能快速暴露启动阶段的元数据不可用问题
建议经验值（可按稳定性与实时性取舍）：
- 迁移/扩缩容频率低：30s~2min
- 需要快速切换：5s~15s（注意元数据服务压力与抖动）
6. 指标 Metrics：上线后你该看什么
Dynamic Kafka Source 除了继承 KafkaSourceReader 的常规指标外，还额外暴露一些对“动态订阅”很关键的指标，例如：
kafkaClustersCount：当前 reader 正在读取的 Kafka 集群数pendingRecords：分区待消费记录数（lag 侧的一个视角）watermarkLag、currentEmitEventTimeLag：事件时间与发射时间滞后sourceIdleTime：空闲时间（可能因为订阅被切走/无数据/被降级）
上线排障时常见观察路径：
- clustersCount 是否符合预期（迁移时是否完成切换）
- pendingRecords 是否异常增长（切换带来的 lag 或消费者组问题）
- watermarkLag 是否突刺（乱序/水位策略/切换瞬间的空洞）
7. 运行原理：为什么它能动态换集群
在 FLIP-27 的新 Source API 抽象下，它大致由四块组成：
- Split：代表某个 cluster 的某个 topic partition（包含 cluster id + KafkaSourceSplit）
- Enumerator：启动时发现元数据并分配 splits；周期轮询元数据变化；发送事件触发 reader 协调
- Reader：内部复用 KafkaSourceReader 去真正拉取数据；收到变更后可能重建 reader 去适配新集群/新 topic
- MetadataService：你提供的真相来源（返回 cluster、topics、连接 properties 等）
这套设计本质上是把“变更入口”统一收口到 MetadataService，再由 Flink Source 在运行时做 reconcile。
8. 落地注意点与最佳实践
元数据服务要做到“强一致”或“最终一致但可收敛”
- 迁移切换时避免来回抖动（比如 A/B 集群频繁翻转）
变更策略要可控
- 是双读一段时间再单读，还是直接切换
- 这些策略通常应由元数据服务侧实现（返回的 metadata 决定读哪些集群）
discovery-interval不宜过小- 太小会让 Enumerator/元数据服务承压，还可能造成频繁 reconcile
关于端到端 exactly-once
- 仍要配合 checkpoint、sink 事务/幂等能力
- 动态切换时要重点验证 offset 提交与 state 恢复语义（尤其跨集群迁移）
