kafka streams 的物化窗口存储（如 `windowstore`）按键（key）而非分区（partition）进行逻辑隔离；相同 key 的记录无论来自哪个输入 topic 或哪个 partition，只要被同一任务（task）处理，就会聚合到同一窗口状态中，不会因 topic 不同而意外覆盖——这是由 kafka streams 的任务分配与键空间统一性保证的。
在您提供的拓扑中，stream(“topic1”, “topic2”) 将两个 topic 作为联合源读取，并通过 .groupByKey() 对所有流入记录按 key 聚合。关键在于：Kafka Streams 并不为每个 topic 单独创建独立的状态存储实例，而是为整个拓扑中的指定 storeName 创建一个共享的、全局唯一的物化存储（Materialized Store）。该存储的底层实现（如 RocksDBWindowStore）以 (key, window-start-time) 为复合主键进行索引，因此：
- 相同 key + 相同窗口区间 → 唯一状态条目（会被聚合更新）；
- 相同 key + 不同窗口区间 → 独立状态条目（互不影响）；
- 不同 topic 但相同 key + 相同窗口 → 仍写入同一状态条目，触发聚合逻辑（如 ObjectAggregator） —— 这正是您观察到“不会覆盖”的本质：不是避免写入，而是设计上支持跨 topic 的键级归并。
为什么不会发生意外交互或状态污染？
Kafka Streams 的任务模型确保了数据一致性：
- 每个 Task 绑定一组同编号 partition（例如 topic1-2 和 topic2-2 同属 Task 2_2），即分区对齐（partition co-location）；
- 所有发往该 Task 的记录（无论来自 topic1 或 topic2），在调用 .groupByKey() 时均基于其 record key 进行哈希路由；
- 因此，只要 key 相同，就必然落入同一 Task 的同一窗口状态槽位，由同一个 aggregate() 实例处理 —— 这是语义正确性的基础，而非副作用。
✅ 正确示例（验证 key 隔离性）：
