📚 课程目录第4章部署架构设计

4. 部署架构设计：主从复制、读写分离与多活架构的选型与对比

在数据库可靠性项目中，部署架构直接决定了系统的可用性、扩展性、数据一致性以及运维复杂度。本章围绕三种主流架构——主从复制、读写分离与多活架构，从原理、适用场景、可靠性指标及选型策略进行系统对比。

4.1 主从复制架构

主从复制是数据库高可用的基础形态。主节点（Master）处理所有写请求，通过异步或半同步方式将变更日志（如 MySQL 的 binlog）同步到从节点（Slave）。从节点通常作为热备份，在主节点故障时手动或自动提升为新主。

  核心特征： 数据单向复制，主节点承担全部读写压力，从节点仅用于备份或只读查询（需应用层控制）。

4.1.1 可靠性指标

指标	说明
RPO	异步模式下可能丢失最后几秒数据；半同步可降至零丢失
RTO	手动切换分钟级，自动切换（如 MHA、Orchestrator）秒级到分钟级
一致性	最终一致性，主从延迟可能导致读取过期数据

4.1.2 适用场景

中小规模业务，对写扩展性要求不高
需要低成本实现数据冗余和灾备
可接受秒级故障切换和少量数据丢失

4.2 读写分离架构

读写分离在主从复制基础上，通过代理层（如 ProxySQL、MaxScale、HAProxy）或应用层路由，将写请求分发到主节点，读请求分发到多个从节点，从而分散读压力。

关键设计点： 读写分离必须解决主从延迟导致的“读不到刚写入数据”问题。常用策略包括：延迟阈值控制、读一致性级别路由、写后读强制走主库。

4.2.1 可靠性指标

指标	说明
RPO	同主从复制，取决于主从同步模式
RTO	代理层可自动剔除故障节点，读故障秒级恢复；写故障同主从复制
一致性	读写分离引入“读延迟”风险，需业务层或代理层补偿

4.2.2 适用场景

读多写少、读负载远高于写负载的业务
需要水平扩展读能力，但写节点仍为单点
对一致性要求不苛刻，可接受最终一致性

4.3 多活架构

多活架构（Multi-Active / Active-Active）允许在多个数据中心或多个地域同时处理读写请求，每个节点均可读写，通过数据层双向复制或分布式共识协议（如 Paxos、Raft）保证最终一致性或强一致性。

注意： 多活架构的复杂度远高于主从复制和读写分离。主要挑战包括：冲突解决、时钟偏差、网络延迟、跨地域事务支持。建议仅在业务规模大、可用性要求极高（如金融核心、全球化业务）时采用。

4.3.1 可靠性指标

指标	说明
RPO	强一致方案 RPO=0；最终一致方案可能丢失少量数据
RTO	秒级自动切换，GSLB 探测故障后立即路由到健康数据中心
一致性	支持强一致（分布式事务）或最终一致（异步复制），需业务权衡

4.3.2 适用场景

全球化业务，需要就近接入、降低跨地域延迟
金融、电商等要求 99.99% 以上可用性的核心系统
具备较强基础设施和运维团队，能处理分布式一致性复杂问题

4.4 架构选型对比总表

维度	主从复制	读写分离	多活架构
写扩展性	无（单点写）	无（单点写）	强（多节点写）
读扩展性	弱（依赖从节点）	强（水平扩展从节点）	强（多地域多节点）
RPO	秒级（异步）~ 0（半同步）	秒级（异步）~ 0（半同步）	0（强一致）~ 秒级（最终一致）
RTO	秒~分钟级	秒~分钟级	秒级
一致性	最终一致性	最终一致性（有延迟窗口）	强一致 / 最终一致可选
运维复杂度	低	中（需代理层）	高（冲突、网络、时钟）
成本	低	中	高（多机房、专线、硬件）
典型场景	中小业务、灾备	读密集型业务	全球化、金融核心

4.5 选型建议

  选型决策树：

如果业务规模小、写压力低、预算有限 → 主从复制

如果读负载远高于写负载，且可接受最终一致性 → 读写分离

如果要求两地三中心、RTO<10秒、RPO=0，且具备分布式运维能力 → 多活架构

如果业务处于快速增长期，建议从主从复制起步，逐步演进到读写分离，最终按需升级为多活。

在实际项目中，架构选型不是一成不变的。建议在项目初期采用主从复制 + 读写分离代理的组合，既保证基础高可用，又为后续扩展预留空间。当业务进入全球化或金融级可用性要求阶段，再投入资源建设多活架构。