自测题库与面试准备

概念层（6.A）

1. KStream = append-only 的 INSERT 日志，同一个 key 来多条记录全部保留（每条都是一个独立事件）。KTable = 按 key UPSERT 的 changelog，同 key 后到的值覆盖先到的，null 值是 tombstone（删除该 key）。GlobalKTable = 每个实例都消费该 topic 的所有分区、持有全量副本，启动时 eager 加载——因此 join 时免共分区，但只适合小而慢变的维表。
2. 流表对偶 = 流和表是同一条日志的两种视图：table 是 changelog "每 key 最新值" 的物化（把日志按 key 折叠成当前状态），stream 是 table 的差异日志（把状态变化展开成事件序列）。正因为这个双向性，状态才可恢复——把 changelog 从头回放一遍就能重建出 table，所以本地状态丢了也不怕。
3. task 数 = 子拓扑输入 topic 的分区数（取最大输入分区数），运行时钉死不可改。num.stream.threads 只控制每个实例起几个 StreamThread，不决定 task 总数；task 在所有实例的所有线程间分配。要改 task 数只能重分区输入 topic。
4. 并行上限 = 最大输入分区数（= task 数）。实例数或线程数加到超过它，多出来的实例/线程会被分到零个 task、CPU 空转，吞吐不再增长。越过这个上限的唯一办法是重分区输入 topic（破坏性操作）。
5. 裸 consumer 只给你"读到消息"。Streams 在其上加了：有状态算子（聚合/count/reduce）及其容错（changelog + standby）、窗口与事件时间处理、join（含自动 repartition 与共分区校验）、EOS v2 端到端精确一次、以及把这些架在消费组之上的缩放/再平衡。只要不需要这些，裸 consumer 就够。
6. stateless：map、filter、flatMap、branch（还有 merge/peek）——逐条处理、不依赖其它记录。stateful：aggregate、count、reduce、join、所有窗口算子——需要跨记录维护状态，因此要状态存储。判断依据：处理这一条时是否需要"记住"别的记录。
7. topology = source → processor → sink 的算子有向图，Streams 把 DSL 编译成它。当流中出现需要重分区的边界（改 key 后接 stateful 算子，要经 repartition topic 重新洗牌）时，拓扑会在那里被切成多个 sub-topology——每个子拓扑独立调度成 task。

原理层（6.B）

1. 每次对状态存储的 put 同时写一条内部 changelog topic（log-compacted）。本地 RocksDB 只是物化视图，真相源是 changelog。故障转移：新 owner 没有本地副本，就从 changelog 回放逐条重建 RocksDB 后再处理；配了 standby 副本则由一直尾随 changelog 的热备秒级接管，跳过大部分回放。
2. 聚合和等值 join 要求相同 key 的记录落到同一个 task / 分区（共分区）。改 key 的操作打乱了原有分区，所以 Streams 在下游 stateful 算子前自动建一个内部 <app>-<name>-repartition topic，把数据按新 key produce 进去再重新消费回来。代价：每个改 key 的操作前置一次 produce→re-consume 往返（延迟 + broker 磁盘 + 额外 topic）。注意 selectKey 本身是 lazy 的，只有下游真依赖 key 的算子才物化出 topic。
3. stream-time = 该 task 见过的所有记录的最大时间戳，只前进不回退，用来驱动窗口关闭与迟到判定。它只在有记录到达时推进。低流量或空闲分区上没有新记录，stream-time 就冻结，窗口永远等不到 windowEnd + grace、结果永不发——表现为"结果卡住不出来"。
4. grace period = 窗口结束后迟到事件还能更新该窗口结果的时长；过 windowEnd + grace 的迟到事件被静默丢弃（只计入 dropped 指标）。retention = 窗口状态/changelog 在存储里保留多久，必须 ≥ 窗口 + grace，否则窗口还在 grace 内状态就被清了。suppress(untilWindowCloses) = 抑制中间结果，每个窗口只发一个最终结果（代价：要等窗口关，增加延迟；内存压力下若用 emitEarlyWhenFull 会发非最终结果，要"最终"必须 shutDownWhenFull）。
5. KStream-KStream：窗口化 join，两侧入库缓冲，窗口+grace 内每对匹配各发一次。KStream-KTable：查表 join，流记录探当前表值；表更新不反向触发。KTable-KTable：维护式，任一侧更新都重新发结果。外键 join：按 value 提取的 key join，Streams 建两个隐藏 topic（subscription + response）+ 复合 RocksDB 存储。前三种等值 join 要求共分区（相同分区数 + 相同分区方式）；GlobalKTable join 和外键 join 免共分区。
6. 把 offset 提交 + 状态 changelog 写 + 输出 produce 三件事绑进一个 Kafka 事务，下游 read_committed 跳过 aborted。v2（KIP-447）相比 v1 改成一个线程一个 producer 覆盖该线程的多个 task，而 v1 是一个 task 一个 producer。高分区数下 v1 会产生海量 producer（爆炸），v2 因此不爆。
7. RocksDB 的 block cache（≈50MiB）和 memtable 分配在 JVM 堆外（off-heap），-Xmx 只管堆内、管不到它；而且每分区每 store 各占一份，分区多则堆外内存线性增长。容器里表现为 JVM 堆指标正常、Pod 却被内核 OOMKilled。选 RocksDB + changelog 而非远程状态库：本地读亚毫秒、无逐条网络跳，且 Kafka 的 compacted 日志本身已是复制/HA 层，不必再引第二个集群化数据库。
8. standby 副本 = 在另一个实例上预先维护一份尾随 changelog 的热备状态。主 task 故障时，已追平的 standby 直接接管，跳过从零回放 changelog，把故障转移从分钟级压到秒级。代价：额外的磁盘 + 网络（每个 standby 都在持续拉 changelog 保温）。

应用判别层（6.C）

1. 部署形态：Streams 是嵌进你应用的库，没有独立集群，跑在消费组上、用普通 JVM 部署；Flink/Spark 是独立集群，要单独的 JobManager/TaskManager 或 Spark 集群运维。处理模型：Streams 逐条处理、容错靠 changelog 复制；Flink 逐条但容错靠分布式快照 checkpoint；Spark Streaming 是微批。Streams 更省心的场景：源和汇都在 Kafka、想避免再养一个集群、Java 后端就近嵌入。Streams 不够用的场景：需要跨多种数据源/汇、复杂 CEP、ML pipeline、或要 Flink 那种独立 checkpoint/状态后端能力。
2. 无状态单纯转发不该上 Streams——裸 consumer/producer 就够，还少一层抽象和内部 topic 开销。值得引入 Streams 的那条线：出现有状态需求（聚合/count/reduce）、窗口/事件时间、join、或端到端 EOS 中任意一项时。判据是"是否需要跨记录的状态或时间语义"，不是数据量大小。
3. 三类即使数据在 Kafka 也不该用 Streams：① 源汇主要不在 Kafka（比如主要从 DB/HTTP 拉、写第三方系统）——Streams 的所有机制都围绕 Kafka topic，离开 Kafka 它的优势全失；② 需要复杂 CEP / ML / 跨多集群的能力——Streams 的算子模型撑不起，该上 Flink；③ 只是简单消费没有状态/窗口/join 需求——上 Streams 是过度设计，徒增内部 topic 与运维面。
4. groupByKey() 不改 key，下游聚合不需要 repartition，没有额外内部 topic。groupBy((k,v)->...) 改 key，下游聚合会自动建 repartition topic 把数据重洗一遍——多一次 produce→re-consume 往返（延迟 + broker 磁盘）。默认优先 groupByKey。只有当确实需要按一个不同于当前 key 的字段聚合时，才不得不用 groupBy（这时重分区是必要代价，不是浪费）。
5. "小而慢变"的维表选 GlobalKTable join：免共分区（主流不必按维表 key 重分区）、查表式语义简单；代价是每个实例都持有全量副本（磁盘 + 内存 + 启动 bootstrap 延迟）。普通 KTable-KTable join 要求共分区、状态按分区切分（每实例只存自己那份），适合维表较大、放不进单实例内存的情况。维表涨到几十 GB 时结论翻转：GlobalKTable 的"每实例全量"变得不可承受（内存爆 + 启动慢），应改用按 key 共分区的 KTable join，或用外键 join（按 value 提取 key、免共分区、状态分区化）。