本文详解如何使用 kafka streams 构建“广播式”分支逻辑，使同一条消息依据多个独立条件同时写入多个输出主题，突破 `branch()` 默认互斥行为的限制。
在 Kafka Streams 中，split().branch(...) 的设计初衷是互斥分路（exclusive routing）：每条记录仅匹配第一个为 true 的谓词，并终止后续判断。这导致像 "abcxyz_blabla" 这类同时满足多个条件的消息，只会进入 "abc" 分支（或 "xyz"，取决于定义顺序），无法实现“一发多投”。
要实现真正的非互斥、多目标路由（demultiplexing），核心思路是：放弃依赖单次 split().branch() 链式调用，转而对原始流进行多次独立筛选与转发。
✅ 正确做法：对同一输入流执行多次 filter() + to() 操作
每个 filter() 判断彼此完全独立，互不影响，从而支持消息“重复命中”多个条件：
KStream<String, String> inputStream = builder
.stream("input", Consumed.with(Serdes.String(), Serdes.String()))
.transform(supplier1, "TRANSIT_STORE_NAME"); // 预处理
// 分支 1：含 "xyz" → 发往 output.xyz
inputStream
.filter((key, value) -> value != null && value.contains("xyz"))
.transform(supplier2)
.to("output.xyz");
// 分支 2：含 "abc" → 发往 output.abc
inputStream
.filter((key, value) -> value != null && value.contains("abc"))
.transform(supplier2)
.to("output.abc");
// 分支 3：含 "def" → 发往 output.def（可扩展）
inputStream
.filter((key, value) -> value != null && value.contains("def"))
.transform(supplier2)
.to("output.def");? 关键优势：
- 语义清晰：每个 filter 表达一个正交业务规则；
- 无耦合：新增/删除分支不影响其他逻辑；
- 性能可控：Kafka Streams 会自动复用上游流拓扑（底层共享同一 KStream 实例），不会产生额外网络或序列化开销；
- 兼容状态操作：若需在各分支中维护独立状态（如窗口聚合），可配合 groupByKey().windowedBy(...) 独立使用。
⚠️ 注意事项：
- 避免在 filter 中执行阻塞或高耗时操作，否则影响整体吞吐；
- 若 supplier2 含副作用（如外部 API 调用），需确保其线程安全且幂等——因为同一消息可能被多次执行；
- 日志与监控建议按分支打标（如 "route-to-xyz"），便于问题定位。
总结：Kafka Streams 的 branch() 不适用于多标签广播场景；真正可靠的多目标路由，应基于原始流的多次独立 filter + to 组合实现——它简洁、健壮、符合流处理的声明式哲学，也是官方推荐的惯用模式。
