分库分表与分布式扩展
校招考察频度:☆ 中频(重点常考·大厂分水岭) 一句话速记:分区能扛不上分库,分片键按高基数;雪花 ID 趋势增,跨库关联靠冗余;分布式 PG 选 Citus,透明路由更省心。
分库分表是单库存储容量与磁盘写入吞吐到达物理极限后的终极手段。开篇第一铁律:凡是能通过硬件升级、索引优化和 PostgreSQL 原生声明式分区表解决的场景,绝不要轻易上分库分表! 只有当单机磁盘 I/O 吞吐或连接数彻底成为瓶颈时才考虑拆分。
一、垂直拆分 vs 水平拆分
垂直拆分 vs 水平拆分
- 垂直拆分:
- 垂直分库:按微服务业务边界拆分为独立的物理数据库(如订单库、用户库、支付库),彻底隔离连接池与 I/O 资源;
- 垂直分表:将大表中的冷热字段拆分(如把用户的账号密码等核心热字段留在主表,个性签名、详细档案等大字段拆到扩展表)。
- 水平拆分:
- 同一张逻辑大表的数据,按照某种数学分片算法(如哈希取模、范围)分散存储到多个物理分片节点上;
- 核心解决单机存储容量超标与单点并发写吞吐瓶颈。
二、分片键(Sharding Key)与分片算法
分片键是分库分表架构中最不可逆的核心设计:
- 三大挑选原则:
- 高基数(High Cardinality):取值分布极度离散(如
user_id、order_id),绝不能用“性别”、“状态”等低基数列; - 写均匀(Uniform Distribution):写入流量均匀打散到所有节点,避免单点热点倾斜;
- 高度匹配高频查询条件:尽量让绝大多数 SQL 查询条件中自然包含分片键,实现精准单节点路由(Single-shard Routing),避免全节点广播扫描(Scatter-Gather)。
- 高基数(High Cardinality):取值分布极度离散(如
主流分片算法对比
| 算法类型 | 核心优势 | 致命缺陷与运维成本 |
|---|---|---|
哈希取模(id % N) | 数据分布绝对均匀,无明显数据热点。 | 扩容迁移极其痛苦:当分片数由 4 变 8 时,大量数据需要重新计算位置并迁移。建议按 2 的幂规划容量(双倍扩容只需迁移一半数据)。 |
| 范围分片(按时间/数值范围) | 极其利于范围检索与冷数据直接归档。 | 存在写入热点倾斜:最新的写入流量 100% 砸在最新那张分片上,失去写入分流效果。 |
| 一致性哈希(Consistent Hash) | 增删节点时仅在相邻虚拟节点间迁移局部数据。 | 实现与路由逻辑较复杂,存在雪崩传递隐患。 |
三、分布式全局唯一 ID 体系
分库分表后,单表自带的自增序列(SERIAL / BIGSERIAL)无法再保证全局唯一(各分片各自自增会产生主键碰撞)。
| 方案 | 生成机制与特点 | 适用场景 |
|---|---|---|
| UUID (v4) | 客户端本地完全随机生成 128 位。无序、体积大(36 字符)、导致 B-tree 页频繁分裂。 | 对顺序无任何要求,小体量简单系统。 |
| UUID v7 | IETF 新标准:前 48 位为毫秒级时间戳,天然趋势递增,完美兼容 B-tree 索引插入。 | 现代分布式系统强力推荐。 |
| 雪花算法(Snowflake) | 64 位整型(1 位符号 + 41 位时间戳 + 10 位机器节点 ID + 12 位自增序列号)。趋势递增、高性能、内存生成零依赖。 | 大厂工业界绝对通用首选。需妥善处理机器时钟回拨问题。 |
| 号段模式(Leaf-segment) | 每次向发号器 DB 批量申请一段 ID(如 1000~2000)暂存在应用内存中,双 Buffer 异步预加载。 | 强依赖连续递增、账单、发票流水号等场景。 |
四、跨分片查询的四大工程难题与解法
- 跨分片多表 JOIN:
- 全局广播表(Broadcast Table):数据量极小但全局共享的字典表/配置表,在每个物理分片中都完整复制一份,本地直接 JOIN;
- ER 绑定分片(Colocated Sharding):将父子关联表(如
orders和order_items)强制绑定使用相同的前缀分片键,确保同一订单的主子明细永远落在同一物理分片内部。
- 非分片键复杂多维检索:
- 通过 CDC 机制监听变更,将全量数据异步近实时同步到 Elasticsearch,所有多维搜索走 ES 拿到主键 ID,再回库精准路由点查。
- 分布式深分页(Scatter-Gather Pagination):
- 若查询
LIMIT 10 OFFSET 10000,代理层必须向所有 N 个分片分别请求前 10010 条数据,在内存中归并排序N × 10010行再取最后 10 条! - 解法:严禁任意跳页,强制改用 Keyset 游标分页(带上上一页最后一条的排序值)。
- 若查询
五、现代分布式扩展方案:Citus 分布式扩展
在 PostgreSQL 生态中,除了传统的客户端分片中间件(如 ShardingSphere),微软开源的 Citus 扩展提供了卓越的分布式体验:
- 无缝集成:将 PostgreSQL 原生转换为分布式数据库,由协调节点(Coordinator)自动管理 Worker 节点的分片分布;
- 透明分布式查询:绝大多数标准 SQL、跨节点分布表与参考表(Reference Table)的本地 JOIN 均可透明执行,大幅降低分库分表的技术侵入性。