数据库水平拆分与跨库查询解决方案-源码库

数据库水平拆分与跨库查询解决方案：从单库瓶颈到分布式架构的实战演进

记得去年我们电商系统遇到的那个棘手问题吗？订单表数据量突破5000万，查询响应时间从毫秒级飙升到秒级，高峰期经常出现数据库连接池耗尽。经过几轮技术方案讨论，我们最终选择了数据库水平拆分这条路。今天我就结合这个实战项目，详细分享水平拆分的实施步骤和跨库查询的解决方案。

一、水平拆分的前期准备与策略选择

在动手拆分之前，我们花了整整两周时间进行准备工作。首先要明确的是，水平拆分不是银弹，它会在一定程度上增加系统复杂度，所以必须做好充分的评估。

拆分策略选择：
我们对比了三种主流拆分策略：
1. 按范围拆分：比如按时间范围或ID范围
2. 按哈希取模：对分片键进行哈希计算后取模
3. 按一致性哈希：解决扩容时的数据迁移问题

最终我们选择了按用户ID哈希取模的方案，因为我们的查询模式大多以用户为中心。这里有个关键点：分片键的选择至关重要，我们选择了user_id而不是order_id，因为大部分查询都是基于用户的。

-- 分片规则示例：user_id % 4
-- 分片0：user_id % 4 = 0
-- 分片1：user_id % 4 = 1  
-- 分片2：user_id % 4 = 2
-- 分片3：user_id % 4 = 3

二、分库分表的实际操作步骤

实施拆分时，我们采用了渐进式迁移方案，确保线上服务不受影响。这里分享我们的具体操作流程：

第一步：双写准备
在拆分前，我们先在应用层实现双写逻辑，同时写入原库和新分片库，但读请求仍然走原库。

// 双写示例代码
@Service
public class OrderService {
    
    @Transactional
    public void createOrder(Order order) {
        // 写入原库
        oldOrderMapper.insert(order);
        
        // 根据分片规则写入对应分片
        int shardIndex = order.getUserId() % SHARD_COUNT;
        shardOrderMappers[shardIndex].insert(order);
    }
}

第二步：数据迁移
我们开发了数据迁移工具，将历史数据按分片规则迁移到新的分片数据库中。这里有个坑要注意：迁移过程中要处理数据变更，我们采用了binlog监听的方式确保数据一致性。

#!/bin/bash
# 数据迁移脚本示例
for user_id_range in "0-999999" "1000000-1999999" ...; do
    ./data_migrate_tool --source-db=old_db 
                       --target-dbs=shard0,shard1,shard2,shard3 
                       --user-id-range=$user_id_range
done

第三步：读流量切换
数据迁移完成后，我们逐步将读流量切换到分片库。先切10%的读流量，观察一段时间没问题后再全量切换。

三、跨库查询的四种解决方案

拆分后最大的挑战就是跨库查询。我们实践了四种方案，每种都有其适用场景：

方案一：应用层聚合
对于需要跨多个分片的查询，在应用层分别查询各个分片，然后聚合结果。这种方式简单直接，但性能有损耗。

public List queryOrdersByTimeRange(Date startTime, Date endTime) {
    List result = new ArrayList<>();
    
    // 并行查询所有分片
    for (int i = 0; i < SHARD_COUNT; i++) {
        List shardOrders = shardOrderMappers[i]
            .selectByTimeRange(startTime, endTime);
        result.addAll(shardOrders);
    }
    
    return result;
}

方案二：建立全局索引表
对于需要按非分片键查询的场景，我们建立了全局索引表。比如要按订单号查询，我们在单独的索引库中维护order_id到分片位置的映射。

-- 全局索引表结构
CREATE TABLE global_order_index (
    order_id BIGINT PRIMARY KEY,
    user_id BIGINT,
    shard_id INT,
    created_time DATETIME
);

方案三：使用数据库中间件
我们测试了ShardingSphere和MyCat两种中间件，最终选择了ShardingSphere。它提供了透明的分片和跨库查询能力。

# ShardingSphere配置示例
shardingRule:
  tables:
    orders:
      actualDataNodes: ds${0..3}.orders_${0..15}
      tableStrategy:
        inline:
          shardingColumn: user_id
          algorithmExpression: orders_${user_id % 16}

方案四：异步ETL到查询库
对于复杂的分析查询，我们通过ETL将数据同步到专门的查询库中，这个库保持全量数据，用于复杂查询和报表生成。

四、踩坑经验与最佳实践

在实施过程中，我们踩过不少坑，这里分享几个重要的经验：

分布式事务问题：
跨库操作无法使用本地事务，我们引入了Seata来解决分布式事务问题。对于非强一致性要求的场景，采用最终一致性方案。

分片扩容难题：
最初我们采用简单取模，扩容时需要大量数据迁移。后来改为一致性哈希，大大减少了扩容时的数据迁移量。

监控体系建立：
拆分后监控变得尤为重要。我们建立了完善的监控体系，包括：
– 每个分片的连接数、QPS、慢查询监控
– 跨库查询的响应时间监控
– 数据一致性校验任务

# 监控脚本示例：检查分片数据一致性
#!/bin/bash
for shard in {0..3}; do
    count=$(mysql -h shard${shard} -e "SELECT COUNT(*) FROM orders" | tail -1)
    echo "Shard ${shard}: ${count} records"
done