本文目录导读：
针对关键信息基础设施（关基）场景下的数据库分库分表，路由策略的选择需要在保障高可用、数据一致性、低延迟和可扩展性的前提下，结合业务特性进行设计。
由于“关基”系统（如金融、电力、政务）对数据安全、事务性要求极高，路由策略不能单纯追求性能而牺牲可靠性。
以下是关基场景下分库分表的核心路由策略及技术选型建议：
核心路由策略
路由策略决定了SQL语句（或请求）应该发送到哪个数据库节点（分库）或哪张表（分表）。
哈希取模路由（最常用）
- 原理：对分片键（如用户ID、订单ID）进行哈希计算，然后对分片总数进行取模（
hash(key) % N）。 - 优点：
- 数据分布非常均匀,避免热点。
- 算法简单,实现成本低。
- 缺点：
- 严重缺点：扩展性差，当分片数
N变化时（如从4个库扩到8个库），取模结果会变，导致大量数据需要迁移（Rehash），关基系统通常要求停机时间极短甚至不停机，这会导致巨大的迁移成本和风险。
- 严重缺点：扩展性差，当分片数
- 关基适用场景：分片数在未来3-5年内固定不变，且业务增长可预测。不推荐用于核心交易库（如银行账户余额）。
一致性哈希路由（平衡扩展性）
- 原理：将哈希值空间组织成一个虚拟的圆环（0~2^32-1），数据库节点（物理节点扩展成很多虚拟节点）分布在这个环上，数据通过哈希找到环上的位置，顺时针找到第一个虚拟节点，映射到真实节点。
- 优点：
- 增强扩展性：增加或减少节点时，只需迁移该节点相邻环上的数据，其余数据不动（只需移动总数据的
1/N，而不是全部）。 - 负载均衡：虚拟节点技术能保证物理节点间负载基本均衡。
- 增强扩展性：增加或减少节点时，只需迁移该节点相邻环上的数据，其余数据不动（只需移动总数据的
- 缺点：
- 算法复杂度略高。
- 仍存在少量数据迁移。
- 关基适用场景：大流量、高并发、需要弹性伸缩的互联网核心业务（如支付网关、用户中心），可配合预分片（提前分配大量虚拟分片）来最小化迁移影响。
范围路由（Range-Based Routing）
- 原理：根据分片键的值范围进行路由。
用户ID 1-10000在DB1，10001-20000在DB2，时间维度的表分片也属于此类。 - 优点：
- 扩展性好,新增库仅需定义新的范围，数据无需迁移。
- 非常利于范围查询（如查询某个时间段内的交易记录）。
- 业务理解简单,运维方便。
- 缺点：
- 容易产生数据热点和访问热点，新注册的用户（大ID）集中在最后一个库；或按月分表，月末的库可能压力巨大。
- 数据倾斜风险高。
- 关基适用场景：
- 时间维度（日志、流水、审计表）：可按年/月/周分表。
- 地域维度（用户、分区数据）：可按省份或区域划分，需要配合业务规则（如强制要求SQL带地市条件）。
列表路由（List-Based Routing）
- 原理：将一个键值映射到一组固定的分片节点，VIP用户 -> DB1，普通用户 -> DB2，或根据业务类型（A业务 -> 库组A，B业务 -> 库组B）。
- 优点：
- 隔离性强,不同业务或用户类型物理隔离，有利于权限控制和故障隔离。
- 非常适合多租户（SaaS）或内部多业务线场景。
- 缺点：
- 映射关系固定后,调整困难，属于静态路由。
- 数据分布可能严重不均（如果VIP用户量暴增）。
- 关基适用场景：强制物理隔离的核心敏感数据，政务系统中不同部门的数据必须分库存储，互不相通。
高级：混合路由（Hybrid Routing）——推荐方案
对于关基系统,单一策略往往不够，通常采用两级路由或混合路由：
- 示例：范围 + 哈希
- 第一级（范围）：按时间（如每半年）或按大客户ID范围分库，这保证了时间维度上的扩展性。
- 第二级（哈希）：在同一时间范围或客户范围内，使用哈希取模来分表（或分子库），这解决了热点问题。
- 示例：列表 + 一致性哈希
- 第一级（列表）：根据业务类型或数据敏感性等级（如核心交易库 vs 非核心查询库）选择不同的路由策略组。
- 第二级（一致性哈希）：在核心交易库组内，使用一致性哈希做细粒度分布。
关基场景下的技术实现考量
路由策略最终需要通过中间件或客户端实现，关基系统通常不推荐在应用层硬编码路由（易出错、难运维），而是采用以下成熟组件：
| 组件类型 | 代表产品 | 关基适用性分析 | 关键考虑点 |
|---|---|---|---|
| 数据库中间件（Proxy） | 阿里云 PolarDB-X、腾讯 TDSQL、华为 GaussDB、MyCAT 2 | 首推方案，代理层承载路由，应用透明。 | 需关注中间件本身的高可用（双机热备）、性能损耗（lt;5%）、以及兼容性（SQL语法支持）。 |
| 客户端分片组件（JDDL/ORM） | ShardingSphere-JDBC、TDDL | 适用于低延迟、高吞吐的OLTP场景，路由逻辑在客户端JAR包中，不经过网络代理，性能高。 | 需关注客户端升级的统一性（升级困难）、应用耦合度、以及跨进程数据一致性（如分布式事务）。 |
| 分布式数据库（NewSQL） | TiDB、OceanBase | 终极方案，完全透明，内部自动实现分片和路由（基于Range或Region），上层只连一个DB。 | 对关基而言，其ACID事务、强一致、自动重平衡特性非常友好，但需注意硬件成本和运维复杂团队要求。 |
关基路由策略选择建议
- 首选方案：优先考虑NewSQL分布式数据库（如 OceanBase, TiDB），这是目前最符合关基“零改造、强一致、自动故障转移”要求的方向。
- 传统方案选型：
- 如果必须使用分库分表框架：
- 核心交易库（账户、余额）：推荐 范围路由（时间/ID范围）+ 一致性哈希 的混合模式，使用 Proxy中间件 实现，避免客户端改造，分片键必须是强业务主键（如用户ID、交易流水号）。
- 日志/审计/历史库：推荐 时间范围的列表路由（按月或日分表），简单、扩展性好，无需复杂哈希。
- 多租户/安全隔离库：推荐 列表路由（如List-Mapping），强制不同部门或不同安全等级的数据路由到不同物理库。
- 如果必须使用分库分表框架：
- 必须避免的行为：
- 禁止使用“无意义”的分片键（如数据库自增ID），必须使用业务唯一键（如身份证、设备ID、流水号）。
- 避免全局表 JOIN：路由策略应保证关联查询在同一个库内完成，或使用全局表只做码表。
- 避免分布式强事务：关基场景下，尽量减少跨库事务，如果无法避免，需使用TCC（Try-Confirm-Cancel）或SAGA 模式，并做好幂等性设计，而不是依赖简单的“XA协议”（性能差且锁问题严重）。
- 运维保障：
- 路由配置（如分片规则、连接池）必须集中管理（通过配置中心如ZooKeeper、Nacos），且支持灰度发布。
- 必须配套全量数据校验工具和自动故障切换（Failover） 机制。
一句话总结：关基系统的分库分表路由，核心在于牺牲一定的极致弹性，换取极高的稳定性和数据一致性，战略上应首选NewSQL，战术上建议使用“范围+哈希”混合路由，并通过Proxy中间件实现透明化治理。
