论文精读：如何用架构魔法解决“无感迁移”与“读扩展”难题

1.概述

在 Serverless 数据库（Serverless DB）的浪潮中，“按需计费”和“极致弹性”听起来很美，但在底层架构的实现上却暗礁险滩。今天，我们通过剖析阿里云团队的最新论文，来看看 PolarDB Serverless 是如何解决现有 Serverless DB 架构中的两大史诗级难题的 。

2.解决办法

2.1. 破局点一：真正的“无感”跨机迁移（Seamless Migration）

为了让数据库在跨机迁移时，上层应用毫无察觉（不断连、不报错），PolarDB Serverless 采用了两套组合拳。这里，Proxy（代理层）扮演了极其关键的协调者角色 。

1. 代理层的“连接保持” (Connection Maintenance)

所有应用的连接并不是直接打在数据库实例上，而是连接在 Proxy 节点上 。

当底层数据库实例因为资源不足需要跨机迁移时，Proxy 不会切断与业务应用的连接 。

Proxy 会默默挂起应用发来的新请求，并在后台去和新的数据库实例建立连接 。对应用来说，仅仅是感觉某条 SQL 的执行时间稍微变长了一点，但绝不会收到 Connection Lost 的报错 。

2. 底层状态的“活体迁移”

光不断连还不够，正在执行了一半的事务怎么办？这就需要深入到数据库底层的机制了：

• Redo Log 实时同步： 迁移过程中，老实例依然在服务，但它会通过 RDMA 网络，把内存中的 Redo Log（记录了数据的修改）实时、单向地刷到新实例的内存中 。

• Proxy 的“断点续传”魔法： Proxy 节点会非常聪明地缓存每个事务正在执行的最后一条 SQL 语句，并记录与之对应的 Undo Log ID（回滚段 ID） 。

• 无缝接管： 切换到新实例时，如果某个 Query 执行到一半老实例被关了，新实例只需要顺着 Undo Log ID 把这一个未完成的 Query 回滚掉 。然后，Proxy 会把刚才缓存的那条 SQL 重新发送给新实例执行 。

结果： 整个跨机迁移耗时不到 0.5 秒，所有的上下文（包含 Binlog、Redo、Undo、事务锁状态）平滑过渡，业务零报错 。

2.2. 破局点二：只读节点的“强一致性”与“读扩展” (Read Scale-out)

既然主库单点扩容有上限，那最好的 Serverless DB 架构就应该能横向扩展（Scale-out） 。

PolarDB Serverless 打破了传统共享存储架构“只读节点只能做最终一致性”的魔咒 ：

它利用底层机制（结合 RDMA 网络传输时间戳等），实现了在只读节点上也能进行强一致性读 。

借助于此，Proxy 向上层业务提供了一个统一的强一致性 Endpoint（入口） 。

当面临突发的读峰值时，系统不再需要死磕主库的扩容，而是可以在后台默默地横向增加只读节点，并将强一致性读请求通过 Proxy 路由过去 。

结果： 读吞吐量实现了真正的线性增长，避免了单点瓶颈，也减少了由于主库过载而被迫进行实例迁移的概率 。

3. 参考资料

针对 ICDE 2024 PolarDB Serverless 的论文 《Towards a Shared-storage-based Serverless Database Achieving Seamless Scale-up and Read Scale-out》

PolarDB Serverless 的成功，本质上是对 Proxy 代理调度层 与 底层数据库核心（Buffer Pool、Redo/Undo、CDC/Binlog） 的一次深度协同设计。

通过 Proxy 的连接维持与 SQL 缓存 + RDMA 的内存日志迁移，做到了极致的无感弹性缩扩容 。

通过 只读节点的强一致性改造，实现了真正的读写分离与横向扩展 。

这不仅大幅提升了资源利用率，也让 Serverless DB 真正做到了像水和电一样，按需使用，毫无感知。

4. 技术细节

4.1. 核心架构：三层解耦与 RDMA 加速

论文描述的 PolarDB Serverless 架构在传统的“存储-计算分离”基础上，进一步强化了状态的解耦。

• 计算层 (Compute Layer)： 负责 SQL 解析和执行。
• 内存池化 (Memory Disaggregation)： 利用 RDMA 技术实现计算节点间的高速内存访问。
• 共享存储层 (Shared Storage)： PolarStore，所有节点访问同一份物理数据。

4.2. 核心技术：不断连扩容

该论文最重大的贡献是提出了一套 “连接维持 (Connection Maintenance)” 和 “事务迁移 (Transaction Migration)” 策略，将跨机迁移时间缩短至 0.5 秒以内。

A. 连接维持策略（依靠 Proxy）

• 原理： 当调度层决定进行跨机迁移（从实例 A 搬到实例 B）时，数据库代理 (Proxy) 起到了中转站的作用。
• 过程：
  1. Proxy 保留与客户端（应用程序）的 TCP 连接（前端连接）。
  2. 在迁移期间，Proxy 建立与新实例 B 的连接（后端连接）。
  3. Proxy 将原先映射到 A 的流量透明地重映射到 B。
• 结果： 应用程序端完全不感知 IP 变化或连接断开，仅在切换瞬间感受到毫秒级的延迟波动。

B. 事务迁移策略（依靠 RDMA + 物理日志）

这是论文最硬核的部分，解决了在途事务如何“接力”的问题：

• 数据同步： 利用 RDMA 网络将旧实例 A 内存中的关键元数据（如事务状态、未提交的 Undo 信息、Redo 日志缓冲区）实时镜像到新实例 B。
• 查询级同步 (Query-level Sync)：
  1. 迁移瞬间，Proxy 会挂起（Hold）当前正在执行的查询。
  2. 旧实例 A 停止处理，新实例 B 接管。
  3. 关键动作： 新实例 B 会“回滚”掉最后一条由于迁移被中断的 SQL，然后在新实例上自动重新执行该 SQL。
• 结果： 事务不需要全局回滚（Rollback），只是单条 SQL 经历了“重跑”，应用层无感知。

4.3. 读取扩展性与强一致性

• SCC (Strong Consistency Cluster)： 论文提到 PolarDB 默认开启强一致性。
• 机制： 读节点（RO）在处理查询前，通过 RDMA 询问写节点（RW）当前的最新位点（CTS）。如果 RO 节点的数据版本旧于该位点，它会利用 RDMA 直接从 RW 节点的内存中拉取最新的日志进行回放，确保读到的数据永远是最新的。

4.4. 性能数据

• 迁移耗时： 跨机迁移时间从传统的分钟级（搬迁数据+预热）缩短到 0.5 秒以内。
• 性能提升： 在高负载伸缩场景下，由于避免了事务回滚和连接重连的开销，整体系统吞吐量提升了数十倍。

这篇论文的精髓在于：它把数据库代理（Proxy）从简单的负载均衡器，提升成了参与“事务级迁移”的调度中枢；同时利用 RDMA 这种硬件红利，消灭了跨机同步的延迟瓶颈,“如果不重启、不回滚事务，你怎么把一个正在跑的数据库搬走？”——答案就说这篇论文的“连接保持+RDMA状态镜像”。