关系型数据库架构设计：从单库到多活的演进路径

关系型数据库架构经常被过度设计。业务早期就上分库分表、多活、复杂中间件，结果开发效率下降，故障面扩大。成熟的数据库架构不是一步到位，而是随业务规模、可用性要求和团队能力逐步演进。

好的架构要回答四个问题：数据是否正确，性能是否足够，故障是否可恢复，团队是否能运维。

单库阶段

单库不是低级架构。对很多业务，单个高质量 MySQL 或 PostgreSQL 实例，加上合理索引、备份和监控，可以稳定支撑很长时间。

单库阶段重点：

• 清晰数据模型。
• 合理主键和索引。
• 慢查询治理。
• 事务边界。
• 备份恢复。
• 权限控制。

不要在基础能力薄弱时引入复杂分布式方案。复杂度不会消失，只会转移。

主从与读写分离

当读压力上升，可以引入从库。主库负责写，从库承担读。但要处理主从延迟和读己之写问题。

适合读从的场景：

• 报表查询。
• 列表浏览。
• 非强一致详情。
• 后台管理。

必须读主的场景：

• 刚写后的确认页。
• 支付状态。
• 权限判断。
• 库存扣减。

读写分离要有路由策略，而不是简单按 SQL 类型分流。

缓存层

缓存可以降低数据库压力，但会引入一致性问题。适合缓存的数据应具备高频读取、可重建、可容忍短暂不一致的特征。

缓存不应掩盖糟糕 SQL。先把数据库访问路径优化清楚，再用缓存削峰。

分区与归档

数据增长后，历史数据会拖慢查询、备份和维护。按时间分区、冷热归档、历史表拆分，是比分库分表更轻量的演进方式。

例如订单表可以保留近一年热数据，历史订单进入归档库或数据仓库。前台查询走热库，后台历史查询走归档链路。

分库分表

当单实例写入、存储或索引规模接近瓶颈，才考虑分库分表。分片键应与核心访问模式一致，尽量让强一致事务落在单分片内。

分库分表后要解决：

• 全局 ID。
• 跨分片查询。
• 分布式事务。
• 数据迁移。
• 扩容路由。
• 运维监控。

这是架构拐点，不是简单优化。

异地容灾

异地容灾要定义 RPO 和 RTO。常见模式：

• 同城双活。
• 异地主备。
• 两地三中心。
• 云上跨区域复制。

数据层容灾比应用层更难。应用可以多地部署，数据库涉及一致性、延迟和冲突处理。多数业务适合主备模式，真正多写多活需要非常强的业务和数据治理能力。

多活的边界

多活听起来理想，但并非所有数据都适合多活写入。账户余额、库存、订单状态这类强一致数据，跨地域多写会引入高复杂度。

可多活的数据通常具备：

• 用户或租户天然分区。
• 冲突可避免或可合并。
• 本地写入、本地读取。
• 跨区域异步同步。

多活不是数据库参数，而是业务分区设计。

架构治理

无论处于哪个阶段，都要建立治理能力：

• 数据库监控。
• 慢查询治理。
• 容量预测。
• 备份演练。
• 权限审计。
• 变更流程。
• 故障复盘。

没有治理，再高级的架构也会失控。

总结

关系型数据库架构应渐进演进。单库、主从、缓存、分区、分库分表、容灾、多活，每一步都有明确收益和成本。不要为了架构名词提前复杂化，也不要在规模到来时毫无准备。最好的数据库架构，是在当前阶段足够简单，在下一阶段有清晰演进路径。