数据库高并发与高可用架构方案

一、高可用方案（HA, High Availability）

• ​​缓存高可用​​：通过双写和双读主备，或利用缓存集群的数据同步与故障自动转移机制实现。
• ​​数据库高可用​​：
  • ​​读高可用​​：通过读写分离（如MHA）及分库冗余实现。
  • ​​写高可用​​：通过主从双备，结合keepalived与虚拟IP实现自动故障转移。

二、高并发方案

根据业务读写特点选择架构：

• 读多写少、读并发高：采用主从分离。
• 写并发高：采用水平分库。
• 读写并发均高：先进行水平分库，再为每个分库部署主从集群。此外，可使用缓存缓解读并发压力。

2.1 读写分离、主从复制与分组架构

三者指同一架构模型，即主从复制（AB复制）：将主库数据复制到一个或多个从库，主库负责写，从库负责读，通常为一主多从。在高可用场景中常简称为MHA。

2.1.1 优势

• 支持更大读并发与吞吐量，提升读性能；写库独立，提升写性能。
• 读写库分离，减少锁冲突，优化写性能。
• 通过从库冗余实现“读高可用”。
• 易于扩展，增加从库可显著提升读性能。

2.1.2 MySQL主从复制过程（异步）

1. Master开启binlog，记录数据变更。
2. Slave的IO线程向Master请求指定binlog及position之后的内容。
3. Master的IO线程返回对应binlog内容及position。
4. Slave将binlog写入relay-log，并创建master.info文件记录连接信息。
5. Slave的SQL线程监控relay-log，解析并执行SQL，实现数据同步。

2.2 分库分表

2.2.1 水平切分（分片架构）

• ​​目标​​：线性提升写性能，降低单库数据量，解决数据量大导致的写瓶颈。
• ​​常见方案​​：
  • ​​范围法​​：
    • 优点：保持数据顺序；精准控制数据量；易于扩展。
    • 缺点：负载可能不均衡（如新用户更活跃）。
  • ​​哈希法​​：
    • 优点：数据与请求分布均衡。
    • 缺点：扩展时需数据迁移；一致性哈希可缓解此问题。
  • ​​哈希+范围混合分片​​：折中方案，均衡数据与请求分布。

2.2.2 垂直切分

• ​​垂直分表​​：将低频或大字段拆分到扩展表，提升内存命中率与IO性能。
• ​​垂直分库​​：按业务拆分库，降低单库数据量，需结合业务可行性。

2.3 读写分离与分库分表结合

结合两者以进一步提升性能，但架构复杂度较高。

三、常见问题与解决方案

3.1 读写分离与水平分库的区别

• ​​数据量​​：主从分离各节点存全量数据；水平分库各节点存部分数据（1/n）。
• ​​目标​​：主从分离扩展读性能；水平分库扩展写性能。
• ​​场景​​：读多写少用主从；写多用分库；读写均高则先分库再主从。

3.2 主从分离的问题

• 写节点单点风险，需通过主从双备+keepalived+虚拟IP实现高可用。

3.3 数据库架构选型

• 初期：单库。
• 读压力大：分组（主从）。
• 数据量大：分片（水平分库）。
• 属性访问频次高：垂直拆分。

3.4 水平切分：分库 vs. 分表

• ​​优先分库​​：避免磁盘IO竞争；易于扩展与迁移。

3.5 瞬时高并发处理

• 通过MQ消息队列削峰填谷。

3.6 分库后的业务接入与数据访问

• 通过代理切换数据源，业务层无感知。
• 数据访问层需处理分片路由与数据聚合，可引入数据库中间件简化。

3.7 非Partition Key查询处理

• ​​全库扫描​​：效率低，但可并发优化。
• ​​索引法​​：建立映射表或缓存（如用户名映射主键）。
• ​​基因法​​：通过非Key属性生成分片位（如用户名生成分片基因）。
• ​​直接生成主键​​：风险为ID冲突，需确保均匀分布。

3.8 多非Partition Key查询

• 对不可修改字段使用基因法，其他用索引法。

3.9 Partition Key批量查询

• 法一：访问所有库，合并结果。
• 法二：按路由规则只访问相关分片。

3.10 跨库分页与模糊查询

• 跨库分页为业界难题，有多种方案。
• 模糊查询或范围查询可借助ES等搜索引擎。

3.11 分库数据量与唯一主键

• 数据量建议：无复杂查询时5千万–1亿条；有复杂查询时1千万–2千万条。
• 唯一主键通过分布式ID生成器实现。

3.12 主从架构中的多主多从

• 建议一主多从；若写瓶颈，可水平分库，每分片部署主从。
• 多主多从需确保数据全量同步，避免数据不一致。

3.13 缓存的作用

• 缓存高频、低频变数据，降低数据库压力，提升响应速度。

3.14 主从切换数据丢失与避免

• ​​丢数据风险​​：
  • 主库未完全同步时宕机。
  • 脑裂导致老主库仍接收写入。
• ​​恢复​​：通过备份的binlog人工恢复。
• ​​避免​​：
  • 使用双主热备+keepalived。
  • 切换前设置主库只读。

3.15 单库重启与连接管理

• 重启通过redo log恢复数据，不丢数据。
• 切换时可配置是否断开连接，如MHA可通过脚本控制。

3.16 分库分表依据

• 单表数据量大导致SQL延迟高：分表。
• 实例QPS达到上限、锁冲突严重：分库。

3.17 主从Binlog同步方式

• 备库指定起始binlog位置后，主库主动推送新日志（基于长连接）。