原子调度
调度能力指调度引擎（MC）与存储引擎（TDStore）之间的交互方式，关注如何高效、可靠地执行数据移动、副本管理等物理操作。
原子调度起源：TDSQL Boundless 实现了 Data/Ctrl Plane Separation 架构
1. 控制平面与数据平面分离 (Ctrl/Data Plane Separation)：MC 作为集群的“大脑”，承担所有控制平面（Ctrl Plane）的功能，包括监控、决策和调度。这使得计算引擎（SQLEngine）和存储引擎（TDStore）可以专注于数据流相关的操作和性能优化，职责清晰，架构简洁。
2. MC 负责各层级资源尤其是存储层的监控和调度。
原子调度起源：TDStore 存储层资源状态与调度任务
调度引擎（MC）需要处理诸如数据分片（Region）跨节点迁移等复杂任务。这类任务从业务视角看是单一的，但在内部涉及多个子步骤，例如：在新节点上创建副本、从主副本同步数据、更新Raft组成员配置、清理原有副本等。以副本迁移（Replica Migration）为例，其内部就包含多达5个子任务。
核心挑战在于若将这类多步骤任务的调度与协调逻辑直接放在存储层（TDStore），会带来显著问题：
1. 逻辑过重：存储层需要同时处理关键的数据读写和复杂的调度逻辑，这会增加其负担，可能影响核心业务的性能与稳定性。
2. 状态混乱：任务的推进、暂停、回滚等流程如果由被执行者（存储节点）自行判断，会引入复杂的二级状态，在异常发生时难以保证状态的一致性，使问题排查和恢复变得异常困难。
为解决上述问题，TDSQL Boundless 将复杂的调度逻辑上移至拥有全局视角的调度引擎（MC）。在 MC 中，我们将每一个调度操作（如迁移、分裂）抽象为一个 Job。每种 Job 类型都有明确的状态机，并被分解为一系列顺序执行的原子步骤（Atomic Step）。
根据调度对象的不同，任务粒度也有所差异：
Replica 级任务：操作相对集中在单个节点上，例如下线并清理某个特定副本。
Rep Group 级任务：通常涉及多个节点（因高可用架构为一主多副本），例如需要在一个 Region 的所有副本上同步执行分裂操作。
Region 级任务：粒度更细，仅涉及 Region 部分元数据的更改。
对象 | State | JobType |
Rep Group | UNINIT NORMAL OFFLINE | CREATE SPLIT MERGE OFFLINE ONLINE DELETE |
Replica | UNINIT ONLINE PENDING DOWN OFFLINE | CREATE OFFLINE ONLINE MIGRATE REMOVE DESTROY PROMOTE/DEMOTE TRANSFER LEADER |
Region | UNINIT NORMAL | CREATE SPLIT MERGE DELETE |
解决方案：MC 承担总 Coordinator，TDStore 作为被动执行者
为平衡性能与可扩展性，TDSQL Boundless 确立了明确的职责划分：调度引擎（MC）作为全局的总协调者（Coordinator），而存储引擎（TDStore）作为被动执行者。
以 Region 为单位的细粒度锁，分离 Region 的状态和调度 Job 状态，最大程度减少调度任务对前端请求的影响。
MC 定义 Atomic Step 任务状态机全集，每个 Job 包含一个或多个 Atomic Step。
TDStore 的 Region 层在任意时刻，最多只会收到并执行单个 Atomic Step。
TDStore 对 Job 推进或回滚无感知，正常推进或回滚全由 MC 掌握。
如下所示，一个 RG 副本迁移（Replica Migration）Job 可分解为以下五个原子步骤：
1. Create： 在目标节点创建新副本。
2. Add：新副本从主副本同步数据。
3. Offline：下线旧副本。
4. Remove：变更 Raft 组配置，移除旧节点。
5. Destroy：在旧节点清理副本数据。
执行流程与回滚：MC 依次下发每个步骤。例如，若步骤1（Create）失败，MC 会立即触发预定义的回滚流程，指令 TDStore 清理已创建的资源。TDStore 只负责执行“回滚”这个原子指令本身，而整个失败处理和回滚决策完全由 MC 控制。
数据感知
拓扑感知(Topology Aware)的数据对象生命周期管理，贯通逻辑层<->物理层链路
1. 管控调度引擎基于 Data Object 抽象，建立拓扑感知的数据对象管理体系， 打通数据逻辑层与物理存储层的链路。
该体系基于 MySQL 关系型模型，对常见数据类型进行分层定义，形成清晰的拓扑结构：
L0 级：Database（数据库）
L1 级：Table（表），隶属于某个 Database
L2 级：Index/Partition（索引或分区），隶属于某个 Table。若为分区表，则进一步区分一级分区、二级分区及其对应索引。
这种层级编码使系统能够精确定位每一个数据对象的逻辑归属。例如，对象10010可明确表示：它是数据库（ id:1） 中分区表（id:1001）的一级分区 （id:1003）下的一个二级索引。
该体系的核心价值在于感知数据之间的亲和性关系。例如，同一张表的主数据与其二级索引、同一分区下的不同子表，在业务查询中极有可能被同时访问。通过拓扑感知，调度引擎能够识别这些逻辑上紧密关联的数据对象，并在物理调度时尽可能将其放置在相同或相近的存储节点。这样做可显著减少跨节点数据访问、降低分布式事务比例，从而提升查询性能与响应速度。
通过 Data Object 与 Region 的关联，该系统实现了逻辑层与物理层的有效贯通：
逻辑层（Data Object）：代表 TDSQL Boundless 中的库、表、索引等逻辑实体。
物理层（Region）：对应 TDStore 中管理的一段连续 Key Range，是数据的实际存储单元。
每一个 Region 都明确归属于某个 Data Object，存储其对应的物理数据。调度引擎（MC）借助这套映射关系，既能理解数据的业务语义，又能掌握其物理分布，从而做出兼顾业务亲和性与存储均衡性的智能调度决策。
2. 管控调度引擎切入 DDL 关键路径 ， 将 DDL 任务映射为对存储层的数据分片的原子调度操作，维持了存储层的 KV 语义独立性。
其核心流程与机制如下：
2.1 DDL 任务解析与元数据管理
当计算引擎接收到前端发起的建表、删表等 DDL 语句后，会将其解析为标准的 DDL 任务。该任务本质是对全局元数据进行“增删改”的操作，以此实现数据对象（Data Object）的生命周期管理。例如，创建表对应生成一个
Create 任务以新增 Data Object，删除表则对应一个 Destroy 任务。2.2 拓扑感知与亲和性调度
调度引擎（MC）通过 RPC 机制感知到数据对象的变更后，会立即将其纳入拓扑感知数据管理体系中。该系统能精准识别数据对象间的亲和性关系（如主表与索引）。当需要创建新的数据分片（Region）时，MC 会基于此亲和性信息，下发调度任务（Job）给存储层（TDStore），智能地将关联紧密的数据对象调度到相同的物理节点上。
2.3 维持存储层语义独立性
整个流程的关键优势在于，存储层（TDStore）完全无需理解复杂的 SQL 语义。它仅需执行由 MC 下发的原子性操作指令（如“创建某个 Key Range 的Region”或“删除某个 Region”）。这种设计将业务逻辑与存储实现彻底解耦，确保了存储层只需专注于高效的 KV 读写与副本管理，维持了其核心语义的独立性和纯粹性。
通过这一机制，调度引擎既实现了基于业务逻辑的智能数据分布优化，又避免了对底层存储的过度侵入，构建了一个既高效又灵活的存算分离架构。
3. 管控调度引擎维护和更新全局库表对象的物理路由信息，聚合物理层读写统计汇合成对象层的热点统计，为基于数据感知的调度策略提供底座能力。
基于复制组（ReplicationGroup）的两层元数据管理以及 On-Demand 分配机制
基于数据拓扑感知的能力，以 On-Demand 机制为计算引擎分配存储资源，保持存算分离的语义，存储层与元数据框架升级完全解耦。
与友商在 Region 过大时简单按范围切分的方式不同，TDSQL Boundless 引入了 On-Demand 分配机制，并与数据拓扑感知能力深度结合：
按需分配资源：在执行 DDL 操作（如建表、创建索引）时，调度引擎会根据数据对象的逻辑含义与亲和性关系，向存储层按需申请 Region。例如，创建一张表时，系统会为其分配专属的 Region 资源。
亲和性驱动调度：借助拓扑感知体系，系统能识别出应放置在一起的数据分片。例如，在为某张表创建二级索引时，调度引擎会依据数据层级关系，将索引所在的 Region 与主表数据所在的 Region 调度至同一节点，从而极大减少跨节点访问，降低分布式事务比例。
基于复制组（ReplicationGroup + Region）的两层元数据管理，支持任意数据分片的分裂与合并，优化分布式架构大部分场景下的分布式事务问题。
