PolarDB-X如何在0.5秒内实现"无感切换" ~ 原理篇

在云计算和容器化技术普及的今天，数据库系统需要应对双重高可用挑战：既要防范硬件故障、网络异常等突发意外风险，又要满足滚动升级、弹性伸缩、配置变更等主动运维需求。传统高可用方案在处理计划内切换时往往造成分钟级业务中断，这与现代业务对"持续在线"的严苛要求形成尖锐矛盾。

传统架构的局限性

主从架构的三大困境

传统主从架构数据库，采用client <--> server的链路，只有一个server节点提供读写，另外一个节点作为冗余热备， 在面对主动切换场景时存在三大困境：

1. 数据一致性陷阱：

• 需严格校验日志同步间隙GAP
• 处理半同步模式下的数据丢失风险
• 切换前后需耗费大量时间验证数据完整性

2. 业务连续性断层：

• 主库停写导致30-120秒服务拒绝
• 连接池重建引发会话中断
• 事务回滚造成业务逻辑异常

3. 管控复杂度膨胀：

• 需开发专用组件处理VIP切换、脑裂检测等复杂状态机
• 异常场景回滚机制增加系统脆弱性

分布式架构的新挑战

分布式架构数据库，采用client <--> proxy <--> servers的链路，通过server多分片的设计实现水平扩展，将server主动切换的运维场景细粒度到单个分片进行。但分布式架构下仍然存在新的挑战：

1. 流量失控风险：

• 传统方案切主后直接断连，导致客户端持续向失效节点发送请求
• 引入Proxy实现流量管控后，Proxy自身升级仍面临无感切换失控风险

2. 会话状态丢失：

• 长连接中的临时表、会话变量等上下文信息无法迁移，破坏业务连续性
• 引入Proxy实现会话保持后，Proxy自身升级仍面临无感切换失控风险

3. Proxy代理架构悖论：

• 引入Proxy后，server端存算一体优势被链路跳数增加所抵消
• Proxy自身升级常使用的双进程方式，又仅限制在同机切换， 不适用跨机切换

如何实现真正的“无感切换”？

真正的无感切换方案需同时满足：

• 数据强一致性
• 会话零中断
• 流量自动迁移
• 跨机迁移能力

传统主从架构受限于单机单分片设计，而常规分布式方案又因代理架构产生新的性能损耗和不足，这成为业界长期未解的技术困局。

PolarDB-X的无感切换架构

作为阿里云自主研发的云原生分布式数据库，PolarDB-X通过存算分离架构创新，在计算节点（CN）、存储节点（DN）、元数据节点（GMS）三个层面实现全栈无感切换能力。

核心突破点

1. 两层解耦设计

• 计算层（CN）：无状态设计，提供SQL计算，支持秒级弹性扩展
• 存储层（DN）：基于XPaxos协议的多副本强同步，提供存储高可用服务

2. 计算层CN无感切换

• 双集群热迁移：新建CN集群与旧集群并行运行，负载均衡自动引导新连接
• 智能连接回收：利用连接池生命周期管理，实现旧连接平滑淘汰（而非强制断开）
• 跨机迁移能力：突破传统双进程方案的地域限制，支持AZ级灵活调度

3. 存储层DN无感切换

• 流量控制阶段
• CN实时感知DN状态，Hold住新事务请求同时放行进行中的事务。
• DN保障会话完整性，自适应等待老会话提交完成。
• 事务完结阶段
• DN保障XA事务完整性，自适应等待XA两阶段事务提交完成
• DN保障事务原子提交完整性，自适应等待事务组提交队列中任务完成
• 协议切换阶段
• DN LeaderTransfer指令实现2 RTT内选举切换
• 多副本多数派达成确保强一致性

相比传统主从架构或者分布式架构数据库， PolarDB-X的无感切换差异如下

以一个CN节点和一个三节点的DN集群的简化PolarDB-X为例，通过CN对DN的实时感知，在高可用切换前，CN会Hold住所有新开启的事务，并尽可能将已开启的事务在当前的DN Leader节点上执行完成。当Leader节点执行完成所有事务后，DN集群发生主动切换，CN感知到新Leader节点后，重新调度Hold的业务请求到新Leader节点上执行，实现无感切换。对于涉及多个DN的分布式事务，在处理高可用切换时，逻辑类似，但会有更多的调度策略细节处理，这里不做展开。