云消息队列 Kafka 版在消息平台内建流计算能力，让您无需自建独立的计算集群，即可对写入 Topic 的数据进行实时处理、清洗、聚合与再分发。本文介绍该能力的整体架构、核心组件以及高可用保障机制，帮助您理解其在生产环境下的稳定性与容错设计。
架构总览
流计算能力采用控制平面与数据平面分离的两层架构。控制平面负责作业的解析、调度与生命周期管理，数据平面负责实际的数据处理与状态持有，二者通过外置的元数据高可用存储解耦。这种分离设计使得管控可切换、计算可替换、状态可回放，共同构成流作业的高可用闭环。管控组件与计算组件均具备跨可用区容灾能力。
整体数据流向为：控制平面从元数据高可用存储读取选举与作业信息，向数据平面下发计算任务并收集运行状态；数据平面的多个计算组件并行处理数据，并周期性地将一致性快照落盘到可靠状态存储；当任意组件发生故障时，系统依据外部元数据与最近一次成功快照完成恢复。
核心组件说明
管控组件（控制平面）
管控组件负责 SQL 解析、SQL 调优、作业提交与生命周期管理、资源编排、故障检测与恢复决策，以及一致性快照的协调触发。它本身以主备多实例形态部署：同一时刻仅一个主实例对外服务，其余实例作为热备；当主实例异常时，通过分布式协调完成领导选举并自动切换主备，由新的主实例接管作业管理。作业定义、恢复位点等关键信息不绑定在单一管控进程的内存中，而是持久化到外部高可用存储，避免"管控单点故障导致作业永久丢失"。
计算组件（数据平面）
计算组件负责实际的数据处理与本地状态持有，以分布式多节点集群形态运行，并按作业并行度弹性扩缩。单个节点故障通常会被隔离在受影响任务范围内，系统会触发任务重调度与状态恢复。
管控组件通过持续心跳探活，一旦发现某计算节点失联，便将其上的任务重新调度到健康节点。结合一致性快照，恢复后从最近成功位点继续处理，而非从头重放全部历史数据（需在开启快照的前提下）。
元数据高可用存储 / 分布式协调
该组件持久化作业元数据、主节点选举信息，以及恢复所需的关键指针（如最新完成的一致性快照位置）。它与计算节点解耦，保证在管控主备切换后，系统仍能从统一的元数据继续恢复作业。
可靠状态存储（一致性快照）
作业开启周期性一致性快照后，分布式状态会被对齐到可恢复边界并落盘到可靠存储。该存储是故障恢复的数据基础，保证状态可回放。
高可用保障机制
流计算能力从管控、计算、状态三个层面构建高可用体系。
管控高可用：主备选举 + 元数据外置。 管控组件多副本部署，通过分布式协调完成领导选举；作业定义与恢复位点等关键信息写入外部高可用存储。主管控宕机后，备管控立即接管，依据外部元数据继续管理作业，从根本上规避管控单点风险。
计算高可用：节点替换 + 任务重调度。 计算组件以多节点集群运行，单节点故障被隔离，不影响其余节点。管控组件持续探活，发现节点失联后将其任务重新调度到健康节点；配合一致性快照，从最近成功位点继续处理，最大限度减少重算开销。
状态一致性与 Exactly-once 语义：周期性一致性快照。 作业可开启周期性一致性快照，将分布式状态对齐到可恢复边界并落盘到可靠存储。任意管控或计算故障后，系统加载最近一次成功快照、对齐输入位点后继续运行，从而支撑端到端一致性（具体语义取决于连接器与配置）。公测阶段还可另行提供人工恢复点（只读、可运营回滚），用于版本变更或人为干预场景下的恢复。
应用级故障域隔离
每个流应用拥有独立的管控实例与计算资源视图，应用之间实现故障域隔离。在单个应用内部，"管控主备 + 多计算节点 + 外部快照存储"构成该应用完整的高可用闭环；当应用退出或失败时，其运行时资源随应用一并回收，避免大共享集群"一挂全挂"的故障放大效应，隔离性更好。