电商分库分表路由组件设计与实践

1. 分库分表路由组件引入背景

在业务量快速增长阶段，单库单表的架构往往会遇到性能瓶颈。我最近接手的一个电商项目就面临这个问题——订单表数据量已突破3000万条，查询响应时间从最初的200ms飙升到2秒以上。经过压力测试，发现单机MySQL在5000万数据量时，TPS会下降60%以上。

这种情况下，分库分表几乎是必然选择。但直接硬编码分片逻辑会导致业务代码臃肿，且后续扩容困难。这就是为什么我们需要引入路由组件——它像交通指挥中心一样，自动将数据请求路由到正确的分片节点。

2. 路由组件核心设计思路

2.1 分片策略选型

我们对比了三种主流策略：

1. 哈希分片：对user_id取模
   • 优点：数据分布均匀
   • 缺点：扩容需要数据迁移
2. 范围分片：按订单创建时间范围
   • 优点：利于冷热数据分离
   • 缺点：可能产生热点
3. 目录分片：维护分片映射表
   • 优点：灵活性最高
   • 缺点：引入额外查询开销

最终选择哈希分片为主+目录分片为辅的混合模式。用户维度查询走哈希，商户维度通过目录表路由。

2.2 路由流程设计

java复制// 伪代码示例
public ShardRoute route(String tableName, Object shardKey) {
    // 1. 检查本地缓存
    if(cache.contains(shardKey)){
        return cache.get(shardKey);
    }
    
    // 2. 计算哈希分片
    int hash = hashFunction.hash(shardKey);
    int shardNo = hash % shardCount;
    
    // 3. 查询目录服务（如有覆盖规则）
    ShardOverride override = directoryService.queryOverride(tableName, shardKey);
    if(override != null){
        return override.getRoute();
    }
    
    // 4. 构建路由结果
    return