大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
“我们准备上分布式集群了。”
这句话在技术评审会上经常出现，但接下来讨论的内容，往往不是同一件事。
有人说的是分片：数据按用户ID拆到多个节点，应用层要处理路由，跨分片查询要特殊改写。
有人说的是透明分布式：应用不用改，数据库内核处理数据分布和事务协调。
两个团队说的都是“分布式集群”，但工程复杂度、改造成本、运维方式完全不同。
集中式的三个真实边界——写入TPS撞墙、单表DDL窗口不可接受、在线扩容停机成本过高——踩到任何一个，分布式就成了绕不开的选项。但踩到边界只是起点，真正决定项目成败的，是选了哪条路线。
分布式集群的两条工程路线，本质上在回答同一个问题：分布式的复杂度，由谁来承担？
一、分片集群：复杂度交给应用
分片集群的工作方式是：数据按分片键水平拆分到多个节点，每个节点只存一部分数据。应用层或中间件负责把请求路由到正确的节点。
这条路线的工程特征非常清晰：扩展性强，但代价在应用侧。
应用层需要知道分片规则。一条SQL如果带了分片键，可以直接路由到目标节点；如果不带，就要广播到所有节点再合并结果。跨分片的事务需要应用层引入分布式事务管理器，跨分片JOIN需要在应用层做数据重分布或多次查询合并。
一个被低估的隐性成本是二次分片。业务增长后，原有的分片数可能不够，需要重新划分数据。这个过程涉及海量数据迁移，而且往往不是一次性工作——业务在变，分片策略可能也要跟着变。有团队实测发现，分片架构虽然硬件成本降低了，但运维团队需要额外人力处理数据倾斜和路由故障，实际总拥有成本反而上升。
分片集群适合的场景很明确：数据量极大（单表几十亿行以上）、分片键稳定且高频查询大多带分片键、团队有较强的分布式开发能力。
二、透明分布式集群：复杂度交给内核
透明分布式集群走的是另一条路。它的核心设计目标是：让分布式系统对应用“透明” ——应用连接集群像连接单机一样，不需要感知数据在哪个节点。
技术上的关键组件包括：
统一接入层（Gateway） 。客户端连接的是一个网关节点，网关负责解析SQL、生成分布式执行计划、路由到目标数据节点。应用只需要发送标准SQL，不需要在代码里嵌入分片逻辑。
计算下推。网关将过滤、聚合等计算任务下推到数据节点本地执行，各节点返回局部结果后，由协调节点做最终合并。这减少了跨节点的网络传输量，也是透明分布式在查询性能上不输分片集群的重要原因。
分布式事务内核。这是两条路线差异最大的地方。分片集群的跨节点事务通常依赖外部事务管理器（如Seata）或两阶段提交（2PC），协调开销和故障恢复逻辑由应用或中间件承担。透明分布式集群把分布式事务引擎放进数据库内核，跨节点事务的原子性和一致性由内核保证，对应用透明。
透明分布式集群的代价在于内核复杂度。跨节点事务的延迟天然高于单机事务，这是分布式架构的物理约束，无法完全消除。但它的工程价值在于：应用改造成本被压到了最低。
三、两条路线的工程取舍
| 工程维度 | 分片集群 | 透明分布式集群 |
|---|---|---|
| 应用改造 | 高。SQL改写、路由逻辑、跨分片事务管理 | 低。多数场景仅需切换连接串 |
| 事务一致性 | 依赖外部事务管理器，跨节点ACID保障难度大 | 内核原生分布式事务，对应用透明 |
| 分片键依赖 | 强。分片键选错，后期调整成本极高 | 弱。数据分布策略由内核管理，应用不感知 |
| 故障隔离 | 粒度细。单分片故障不影响其他分片 | 依赖内核的故障切换机制 |
| 运维复杂度 | 高。需同时维护数据库、中间件、路由规则 | 低。运维方式接近单机数据库 |
| 极致扩展 | 更灵活，分片粒度可精细控制 | 受内核实现约束，扩展策略相对统一 |
分片集群的优势在控制力——你能精确控制数据放在哪、怎么路由。代价是复杂度由你承担。
透明分布式集群的优势在工程效率——应用改造少、事务一致性由内核保证、运维方式接近单机。代价是部分控制权交给了内核。
四、金仓KES的两条产品线
金仓KES在分布式方向上用两条产品线对应上面两条路线，核心设计逻辑是不让用户在最开始就被迫做不可逆的路线选择。
KES TDC（事务型透明分布式集群） 对应透明分布式路线。它的核心能力是把数据分布和跨分片事务的复杂度下沉到内核。通过分布式事务协议保证跨分片查询的事务一致性，让开发者像使用单机数据库一样使用分布式集群。对于金融账务、核心交易这类事务一致性优先、应用改造预算有限的场景，TDC的工程价值在于消除了分布式架构对应用层的侵入。
KES Sharding（分片集群） 对应分片路线，面向超大规模数据、需要精细控制数据分布的场景。它在工程上的重点是故障隔离——单个分片故障不影响其他分片的读写——以及对超大规模数据集的横向扩展能力。
两条产品线共享同一套SQL引擎和运维体系，这意味着从TDC向Sharding演进、或者在不同业务模块采用不同路线时，技术栈是连续的。对于正在从集中式向分布式过渡的团队，这种“双模”设计降低了路线切换的沉没成本。
五、选型判断：先回答“谁来承担复杂度”
| 判断条件 | 倾向分片集群 | 倾向透明分布式集群 |
|---|---|---|
| 应用改造预算 | 有充足预算和分布式开发团队 | 预算有限，希望最小化代码改动 |
| 事务一致性要求 | 最终一致性可接受 | 强一致，RPO=0 |
| 分片键稳定性 | 分片键稳定，查询模式清晰 | 分片键可能变化，查询模式多样 |
| 数据规模 | 单表几十亿行以上，需要精细控制分布 | 数亿到数十亿行，增长趋势可控 |
| 团队能力 | 有分布式系统开发和运维经验 | 希望运维方式接近单机数据库 |
一个务实的判断顺序：先确认集中式是否真的到了边界。到了边界之后，应用改造预算和事务一致性要求，往往比数据量本身更能决定路线。预算紧、一致性要求高，透明分布式更务实；数据规模极大、需要精细控制分布、团队有分布式经验，分片集群更合适。
六、小结
分布式集群不是一种东西。分片集群把复杂度交给应用，换来了极致的扩展控制力；透明分布式集群把复杂度交给内核，换来了应用改造的低门槛和事务一致性保障。金仓KES的TDC和Sharding分别对应这两条路线，共享同一套技术栈，让选型不再是“一次定终身”。选型的关键，是诚实地回答一个问题：分布式的复杂度，你的团队想承担多少，又能承担多少。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
