Serverless 数据库与云原生数据库高可用

• Serverless 下连接与容量伸缩的矛盾
• 连接池/代理的职责扩展
• 预热、限流与按需分配

Serverless 数据库的容量会随负载伸缩，但应用建立的连接是长连接，可能被固定在某个实例或与伸缩状态冲突。这对连接池/代理提出新要求：一是连接管理要与容量伸缩解耦，代理应把连接池与应用资源解耦，随容量伸缩动态调整；二是连接预热，避免冷启动时应用连接建立延迟；三是限流与队列，在伸缩上限内保护数据库；四是路由与端点稳定，代理要提供稳定的端点，屏蔽底层实例变化。因此 Serverless 场景常引入数据库代理（如 RDS Proxy），由代理维护连接池、复用连接、缓冲超限请求，并配合容量伸缩。

Serverless 的核心矛盾是"连接是黏性的、容量是流动的"。连接池/代理需要充当解耦层：一方面复用连接减少建连开销，另一方面在容量伸缩、实例重建时对应用透明。代理还能在容量不足时排队，避免打爆数据库。

• 跨区域复制的传输路径
• 复制延迟的组成
• 对 RPO 与读取一致性的影响

Aurora Global Database 的跨区域复制延迟主要来自：跨区域网络物理距离导致的往返时延（RTT）、存储层日志复制与传输的排队/处理时间、次级区域 apply 日志的时间。延迟通常为亚秒到数秒，取决于区域间距离与网络状况。由于复制是异步的，次级区域的数据可能略滞后于主区域，因此次级区域的读一致性是"最终一致"；RPO（恢复点目标）也由该复制延迟决定，故障切换时可能丢失复制延迟窗口内的数据。要降低延迟，可选择区域对更近、走专用网络（如 AWS Global Network）的配置。

跨区域复制延迟 = 网络传播 + 传输 + 应用。它直接决定 RPO 与次级区域读取的滞后程度。理解延迟来源，才能通过选择就近区域、优化网络来权衡一致性与可用性。

• VPC 隔离与私有网络
• 安全组（Security Group）的访问控制
• 加密与密钥管理（KMS）

云数据库（如 Aurora）默认部署在用户 VPC 内，通过私有 IP 提供服务，不暴露公网，实现网络隔离。安全组充当防火墙规则，按来源 IP/端口控制谁可以访问数据库。数据加密方面，云数据库支持静态加密（存储层加密）与传输加密（TLS），主密钥由 KMS（密钥管理服务）管理，用户可控制密钥轮换与权限。此外，可通过 IAM 策略、子网、网络 ACL 进一步细化访问控制。这些集成让数据库"落在一个受控的网络与密钥体系内"。

安全集成是云数据库的标配能力。VPC 提供网络隔离，安全组提供边界访问控制，KMS 提供密钥管理与加密。三层配合，配合 IAM 实现最小权限，共同构成云数据库的安全模型。

• RTO 的组成环节
• 各环节的优化手段
• 秒级 RTO 的实现要点

云数据库故障转移的 RTO 由四个环节构成：故障探测（检测主实例异常）、仲裁（确认故障并决定新主）、端点切换（提升新主并更新/保持端点指向）、应用重连（连接池断开旧连接并连到新主）。逐环节优化：探测侧用快速健康检查与多维度心跳缩短检测时间；仲裁侧用预置的待机副本（如 Aurora 的副本提升）减少提升时间；端点切换侧用稳定集群端点（地址不变）+ 存储层快速接管，避免重建数据；应用重连侧用连接池自动重试、快速失败、预热连接，缩短重连时间。综合优化后，故障转移可达到秒级 RTO。

"秒级 RTO"不是单点能力，而是四个环节的端到端优化：探测要快、仲裁要短、端点要稳、重连要自动。每缩短一环都能降低总 RTO。这也是评估云数据库高可用设计的核心框架。

• ACU 与资源（CPU/内存）的换算
• 扩缩容对现有连接的影响
• 对长连接应用的影响

Serverless 数据库用容量单位（如 Aurora 的 ACU）表示资源，一个 ACU 约等于 2GB 内存和相应的 CPU 与网络资源。扩缩容时，Aurora Serverless v2 通过调整 ACU 改变实例资源，但已建立的连接通常不会中断（v2 在扩容时保持连接，缩容时也尽量保持），因此长连接应用可以继续使用。但需要注意：缩容或容量调整期间，底层资源变化可能短暂影响性能；若容量缩到最低或 (v1) 暂停，连接会中断需重建。因此对长连接应用，应选用支持连接保持的 Serverless 形态（如 v2），并设置合理的 Min ACU 避免缩到 0 导致断连。

ACU 是资源换算单位，扩容加资源、缩容减资源。v2 的伸缩设计尽量保持连接连续，避免长连接应用被频繁打断；但极端的缩容（到 0/暂停）会断连。理解这一点，才能在长连接场景合理配置容量边界。

• 自动备份与快照原理
• 跨区域复制（CRR）备份
• RPO 与恢复点

云数据库（如 Aurora）提供自动备份，备份基于存储层的增量快照与日志，支持按时间点恢复（PITR）。快照是存储层的逻辑副本，成本低、恢复快。跨区域复制（Cross-Region Replication）可以把备份快照异步复制到其他区域，用于异地灾备与容灾，备份副本区域可选择异地。跨区域备份的 RPO 取决于备份复制频率（通常数分钟到小时级），而自动备份 + binlog/日志可提供更细粒度的 PITR。恢复时可在目标区域从快照创建新实例。

备份快照是"恢复点"的基础，跨区域复制提供"异地容灾"。两者结合：快照 + 日志支持秒级 PITR（防误操作），跨区域复制保证区域级灾难时仍有数据可恢复。RPO 由备份频率与复制频率决定。

• 按需启停（暂停/唤醒）机制
• 按用量计费（按秒计费）
• 计费组成部分

Serverless 数据库支持按需启停：无负载时可自动暂停实例（v1 可缩到 0），有请求时唤醒。计费按用量（按秒/按 ACU 小时）计算，只对实际使用的计算容量付费，存储仍按占用空间计费。因此空闲时段成本趋近于零（仅存储），负载高峰按需付费。代价是暂停后唤醒有冷启动延迟（需重新分配资源、加载缓存），不适合要求即时响应或频繁唤醒的场景。计费模型通常分计算（按 ACU 用量）与存储（按存储大小）两部分。

按需启停 + 按用计费是 Serverless 的核心价值：把"预留资源"变成"按需资源"，空闲不花钱。但冷启动延迟是权衡点，需结合业务可用性要求决定是否启用暂停。

• 冷启动延迟的来源
• 连接预热的意义
• 缓解手段

Serverless 数据库在暂停/缩容到最低后，首次请求需要重新分配资源、启动实例、加载缓存，这段"冷启动"时间会造成明显延迟（秒级甚至更久）。连接预热指在流量到来前预先建立并保持数据库连接，避免每个请求都经历建连 + 冷启动。缓解手段包括：设置合理的 Min ACU 避免缩到 0；使用代理（如 RDS Proxy）维护长期连接池、缓冲超限请求；对无状态应用做主动预热/健康检查；或对延迟敏感的业务禁用自动暂停。连接预热与代理配合，能显著降低冷启动对请求的影响。

冷启动是 Serverless 的固有代价。缓解的核心是"不让实例真正冷却"或"隐藏冷启动延迟"：通过 Min ACU 底线、代理连接池、预热来避免逐个请求承担冷启动。这是 Serverless 高可用与延迟体验的关键优化。

• PolarDB 的存算分离架构
• CPU 与内存独立伸缩
• 弹性粒度的优势

PolarDB（阿里云数据库）采用存算分离架构，计算节点与存储分离。其 Serverless 能力支持 CPU 与内存的独立弹性伸缩：CPU 可以按需动态增减（通过调整计算资源），内存资源也可独立配置与扩展，二者解耦，避免"要么一起升要么一起降"的粗粒度。这种独立弹性让资源配置更贴合实际负载，例如高 CPU 型负载只加 CPU、大内存型负载只加内存，从而降低成本。结合共享存储在存储层，扩容时无需重分布数据。

CPU/内存独立弹性的价值在于"按需分项"：不同负载对 CPU 和内存的需求不同，独立伸缩能精准匹配，避免资源浪费。PolarDB 依托存算分离与虚拟化资源调度实现这一能力。

• 多租户隔离的维度
• 资源隔离机制
• 数据隔离与安全

Aurora Serverless 的多租户资源隔离主要体现在数据与安全层面：每个集群是独立的逻辑租户，通过 VPC 隔离、IAM 权限、数据库账号与网络访问控制实现租户间数据与访问隔离。资源层面，Serverless 的容量（ACU）按集群独立伸缩，但共享底层物理资源池；云厂商通过资源调度与限额保证各租户的容量边界，避免相互影响。不过，多租户共享物理资源意味着可能存在邻居噪声（noisy neighbor），极端情况下会影响性能，因此对隔离要求严格的场景可选用专用实例或计算资源。

Serverless 多租户隔离分两层：逻辑隔离（数据、权限、网络）与物理共享（资源池）。逻辑隔离是安全的硬保证，物理共享是成本优化的来源。理解"安全隔离强、物理共享有噪声"的权衡，是评估多租户 Serverless 的关键。

• 扩容的触发与速度
• 扩容上限（Max ACU）
• 突发流量下的限制

Serverless 数据库在突发流量下会自动扩容，但扩容速度与上限受配置影响：扩容速度通常为秒级到分钟级（v2 支持秒级伸缩），存在一定的爬坡时间；上限由用户配置的 Max ACU 决定，容量不可能无限增长。若突发流量瞬间超过 Max ACU 或扩容速度跟不上，数据库会出现性能瓶颈、排队或连接超限。因此对可预测的突发流量，应提前调高 Max ACU 或预留容量；对极端突发，需结合限流、缓存、队列在应用层削峰。缩容是渐进的，避免反复抖动。

Serverless 的弹性是"有界有速"的：有上限（Max ACU）、有爬坡速度。它擅长应对平缓波动，但对"瞬时尖峰"可能不够快。设计上应预留 Max ACU 余量 + 应用层削峰，才能保证突发流量下的稳定。

• 适用场景（负载波动、低频、开发测试）
• 成本构成与权衡
• 不适合的场景

Serverless 数据库适合：负载波动大、难以预测（如季节性流量、定时任务）、低频或间歇使用（如开发测试、演示环境）、节省成本优先的场景。成本权衡：按用量计费，空闲时便宜（仅存储），但若负载持续饱和、长期高并发，按用计费可能比预留实例更贵；且存在冷启动延迟、连接数/容量上限等限制。因此不适合：持续高负载、延迟极其敏感、需要严格性能可控与资源隔离的生产核心业务。选择时需结合负载画像估算 TCO。

Serverless 的成本优势来自"空闲不花钱"，劣势在"高负载单价可能更高 + 冷启动 + 限制"。适用与否取决于负载是否波动、是否间歇、延迟要求、性能可控性。这本质是"按需付费 vs 预留资源"的经济权衡。

• 存算分离与 Serverless 的关系
• 计算弹性与存储共享
• 存储与计算独立伸缩

Serverless 与存算分离天然协同：存算分离把"计算"与"存储"解耦，存储独立持久化、跨节点共享，计算节点可独立伸缩——这正是 Serverless 弹性伸缩的基础。Serverless 让计算容量按需伸缩（加/减计算节点或 ACU），存储则按数据量独立扩展、不随计算抖动。因此协同体现在：计算按需弹性、存储按量付费、扩容无需重分布数据、计算与存储的伸缩互不干扰。这也是 Aurora、PolarDB 等云数据库 Serverless 化的架构基石。

没有存算分离就没有真正的 Serverless 数据库：因为计算节点随时可销毁重建，数据必须依赖独立于计算节点的共享存储。存算分离提供"可无限加计算的底座"，Serverless 提供"按需加计算的策略"，二者结合实现弹性与成本的最优。

• Multi-AZ 的可用性目标
• 跨地域容灾的 RPO/RTO
• 同域 vs 跨域的一致性

Multi-AZ（同区域多可用区）通过把数据库副本/存储分布在不同 AZ，实现区域内的自动故障转移，RPO 通常为 0（同步复制）、RTO 秒级，用于应对机房级故障。跨地域容灾（如 Aurora Global Database、跨区域快照）则是把数据复制到异地区域，用于应对区域性灾难，但跨区域复制是异步的，RPO 取决于复制延迟（秒级到分钟级），RTO 取决于切换与重连（分钟级）。因此设计上：同域 Multi-AZ 解决"可用性"，跨域容灾解决"灾难恢复"，两者结合形成纵深防御。

Multi-AZ 与跨地域容灾的一致性/延迟不同：同域可同步（RPO≈0），跨域异步（RPO 非零）。RPO/RTO 目标不同决定采用哪种层级的容灾。理解"同域同步、跨域异步"是容灾设计的关键。

• 自动故障转移流程
• 端点（endpoint）稳定性的意义
• 如何通过端点路由实现透明切换

云数据库（如 Aurora）提供自动故障转移：主实例故障时自动提升新主，无需人工干预。关键设计是"端点（endpoint）不变"：集群提供一个稳定的集群端点（cluster endpoint），始终指向当前主实例；故障转移后，集群端点自动指向新主，应用通过集群端点连接，无需改动连接地址。读写副本则由只读端点统一路由。这样应用与数据库实例解耦，故障转移对应用透明，只需连接池重连即可。端点的 DNS 解析可能在切换后需要短暂时间更新，因此应用应配合重试。

端点不变是"透明故障转移"的实现手段。应用只认稳定端点，不感知后端实例变化；集群维护端点到实例的映射，切换时自动更新。这让自动化运维可行，也是高可用架构的重要体现。

• 写转发（write forwarding）的机制
• 次级区域承担写流量的方式
• 跨区域延迟与冲突检测代价

Aurora Global Database 的写转发（write forwarding）允许次级区域（secondary）接收写请求，并把该写请求转发到主区域的主实例执行，执行结果再返回次级区域。这样应用可以把写流量分布在靠近次级区域的调用方，降低本地读延迟，同时由主区域统一保证写一致性。代价：跨区域往返延迟（写请求需先发到次级区域、再转发到主区域、结果回传，经历两次跨界往返），写延迟显著高于本地写；同时需要冲突检测机制，即主区域需要判断次级区域转发的写是否与主区域本地写冲突，避免并发写冲突，这增加了协调开销。因此写转发适合"读多写少、写可容忍高延迟"的场景。

write forwarding 让次级区域"就近接写、转给主区域执行"，本质是"把主区域当作写代理"。代价是跨区域 RTT 与冲突检测。它提升了次级的读写能力，但写延迟高、协调复杂，需按业务权衡。

• 存储自动扩容机制
• IO 突发（burst）与信用
• 上限与监控

云数据库（如 Aurora）支持存储自动扩容：存储按数据量自动增长，无需预先规划磁盘大小，按实际占用计费。IO 突发（burst）指实例在短时间内可超出基准 IOPS 处理突发流量，通常通过"IO 信用（credit）"机制实现：实例在低负载时积累信用，突发时消耗信用获得更高 IOPS。但突发受信用上限约束，长期高负载会耗尽信用、回落基准。设计上应监控 IOPS 与信用余量，避免长期透支导致性能下降；也可选择配置更高的基准 IOPS 或 IO 优化实例。

存储自动扩容解决"磁盘不够用"的运维问题；IO burst 解决"短期尖峰"的性能问题，但受信用机制约束。理解"信用耗尽回落基准"的模型，才能避免误判性能问题。

• 只读端点（reader endpoint）的作用
• 读写分离路由
• 负载均衡与一致性

云数据库（如 Aurora）提供分区端点：集群端点（cluster endpoint）指向主实例处理读写，只读端点（reader endpoint）在多个只读副本之间做负载均衡，把读请求分发到不同副本。应用把写操作发到集群端点、读操作发到只读端点，即可实现读写分离。只读端点由集群自动维护，副本增减时自动更新成员。需要注意：只读副本存在复制延迟，读一致性是"最终一致"，对强一致读的应用需走主实例或使用特定机制。

只读端点把"读扩展"抽象成稳定地址，自动负载均衡到多个副本。读写分离路由的关键是"读走副本、写走主"，但必须接受副本的复制延迟，否则会出现读到旧数据。这是读写分离的设计权衡。

• SLA 的可用性指标
• 赔付（credit）条款
• 高可用设计与 SLA 的关系

云原生数据库的 SLA（服务等级协议）通常承诺月度可用性百分比（如单区域 99.99%、多区域更高），并定义"不可用时长"的判定标准（如区域不可达、请求失败等）。当未达到 SLA 时，云厂商提供赔付（service credit），通常是按受影响费用的百分比抵扣，而非现金赔偿。解读 SLA 需注意：SLA 只覆盖"云厂商责任"的故障（如区域/服务故障），不含网络、应用、配置等客户责任；提升可用性等级（如 Multi-AZ、跨区域）可获得更高 SLA 承诺。SLA 是"兜底承诺"，实际高可用还需靠架构设计。

SLA 是商业承诺，赔付是补偿机制（多为服务抵扣），但置信度有限。它不能替代架构设计。理解"什么算不可用、客户责任边界、赔付形式"才能正确评估云数据库的可用性保障。

• 故障转移时连接与事务的终止
• 应用重试与幂等设计
• 连接预热配合端点切换

故障转移时，原主实例上的连接会中断，正在执行的事务被回滚（未提交的变更丢失），应用会收到连接错误或事务回滚异常。应用需设计重试机制：捕获连接中断/事务失败异常，重连新主（通过稳定端点自动指向新主）并重做事务。为保证重试正确性，写操作需具备幂等性或以事务为单位整体重试。连接预热方面，应用/代理应在故障切换后快速重建连接池并预热连接，缩短冷启动；配合端点切换（DNS 更新完成前重试），实现无缝恢复。核心是"故障可感知、重试可安全、连接可快速重建"。

故障转移对应用并非完全透明：进行中的事务会回滚。因此应用必须"重试 + 幂等"。连接池负责在端点切换后重建连接，预热减少建连延迟。这是应用层与数据库层配合实现高可用的关键。