{T}

数据分布:分片与复制

0. 引言

分布式数据库的水平扩展依赖两大机制:**分片(Sharding)**把数据切到多个节点(解决容量),**复制(Replication)**让数据在多个节点保留副本(解决可用性)。两者正交组合构成分布式存储的骨架。本文先讲分片策略与分片键选择,再讲复制的方式、模型与协议。

1. 数据分片:为什么与怎么做

单机数据库受限于磁盘、CPU 与内存,存在存储与算力上限。当数据量或访问量超过单机承载能力时,需要通过分片将数据分布到多个节点,使整体容量与吞吐随节点数增长

1.1 三种分片策略

策略规则优点缺点
哈希分片节点 = hash(shard_key) % N分布均匀,避免热点扩容时 N 变化,几乎所有数据需重分布(Re-sharding)
范围分片按分片键取值区间划分范围查询高效、扩缩容只迁边界数据热点(按时间分片时最新区间写入集中)
一致性哈希哈希环:节点与数据映射到环,归属顺时针最近节点节点增减仅影响相邻区间,迁移量小分布不均有热点,需虚拟节点均衡
图表渲染中…

1.2 分片键的选择

  • 避免高基数但倾斜的键(如大部分数据同属一个租户);
  • 使高频查询尽量落在单一分片,减少跨分片(Cross-Shard)查询;
  • 跨分片事务成本高——分片键设计应尽量让事务局限在单分片内(如按 user_id 分片,用户维度事务天然单分片)。

2. 数据复制:为什么与怎么做

单机存储存在单点故障风险,读能力受限于单机。复制让部分节点失效时系统仍可用,读请求可分散到多个副本提升吞吐。

2.1 复制三问

问题选项说明
复制什么逻辑复制 vs 物理复制逻辑:SQL/行变更;物理:数据页/WAL
向哪里复制拓扑结构主从、多主、无主(全连接)
何时复制同步 vs 异步决定一致性与可用性取舍

2.2 同步 vs 异步

方式行为优点缺点
同步复制主节点等所有副本确认后才返回成功强一致、不丢数据任一副本不可用即阻塞写入,可用性下降
异步复制主节点本地提交即返回,副本后台追赶写入延迟低、可用性强主节点故障可能丢数据;副本读到旧数据

工程折中:半同步复制(MySQL semi-sync:等至少一个副本 ack)、多数派提交(Quorum:等 W > N/2 个确认)——在一致性与可用性之间取平衡,避免"全同步太慢、全异步会丢"。

3. 复制模型

模型写入口适用局限
主从(Single-Leader)唯一主节点读多写少主节点是瓶颈与单点
多主(Multi-Leader)多个节点均可写多数据中心、写冲突可业务化解写冲突需解决策略(LWW/向量时钟)
无主(Leaderless)客户端直写多节点高可用、弱一致(Dynamo 系)一致性模型复杂,需读多写多(Quorum)

4. 复制协议

协议机制优点缺点
基于语句记录并回放 SQL实现简单、日志小对非确定性函数(NOW()/RAND())敏感
基于行(Row)记录每行变更前后值稳健、MySQL 8.0 默认(binlog_format=ROW)大批量更新日志量大
基于 WAL直接传输存储引擎预写日志与主节点状态完全一致耦合存储实现,跨版本兼容困难(如 PostgreSQL 的 WAL 复制)

5. 复制与一致性的关系

复制的同步程度直接决定一致性水平:

text
异步复制 → 最终一致性(副本收敛,窗口期内读旧值)
半同步/Quorum → 近似强一致(多数派即提交)
全同步/多数派 + 线性化读 → 强一致(TiDB/OceanBase 的 Raft 复制)

分布式数据库(TiDB、Spanner、OceanBase)普遍采用 Raft/Paxos 多数派复制:既避免了全同步的可用性短板,又通过多数派保证不丢已提交数据——这是"复制 + 一致性协议"结合的经典形态(详见《如何透彻理解 Paxos 算法?》)。

6. 小结

  • 分片解决容量:哈希(均匀)/范围(有序)/一致性哈希(扩缩容友好),分片键决定查询效率与事务边界;
  • 复制解决可用性:同步/异步取一致性与延迟平衡,主从/多主/无主对应不同写模型;
  • 复制协议:语句(简单)/行(稳健)/WAL(精确);
  • 一致性水平 = 复制同步程度:异步→最终一致,多数派→强一致。

下一章讲解一致性:CAP 与一致性模型在分布式数据库中的落地。