高并发场景下的数据库扩展策略#

一、为什么需要分库分表#

当单库单表面临以下问题时，就需要考虑分库分表：

性能瓶颈#

存储瓶颈：单表数据量超过千万级，索引效率下降
并发瓶颈：数据库连接数、IOPS、网络带宽达到上限
查询瓶颈：即使有索引，大表查询仍然缓慢

典型阈值参考#

单表数据量：500 万-1000 万条
单表存储：20GB-50GB
QPS：单库 5000-10000

二、分库分表策略#

1. 垂直拆分#

垂直分库：按业务模块拆分

1
原单库：
2
- 用户库：用户表、登录表、权限表...
3

4
拆分后：
5
- 用户中心库：用户表、登录表
6
- 订单库：订单表、订单明细表
7
- 商品库：商品表、库存表
8
- 支付库：支付记录表

垂直分表：按字段拆分

1
-- 原用户表（字段过多）
2
CREATE TABLE user (
3
    user_id BIGINT,
4
    username VARCHAR(50),
5
    password VARCHAR(100),
6
    -- ... 20个基础字段
7
    avatar TEXT,           -- 大字段
8
    description TEXT,      -- 大字段
9
    login_history JSON     -- 大字段
10
);
11

12
-- 拆分后
13
-- 基础表（高频访问）
14
CREATE TABLE user_base (
15
    user_id BIGINT PRIMARY KEY,
16
    username VARCHAR(50),
17
    password VARCHAR(100),
18
    -- 常用字段
19
);
20

21
-- 扩展表（低频访问）
22
CREATE TABLE user_ext (
23
    user_id BIGINT PRIMARY KEY,
24
    avatar TEXT,
25
    description TEXT,
26
    login_history JSON
27
);

2. 水平拆分（重点）#

水平分库：将同一张表的数据分散到多个数据库 水平分表：将同一张表的数据分散到多张表

三、分片策略详解#

1. 哈希分片（最常用）#

适用场景：数据分布均匀，按 ID 查询为主

1
// 按用户ID哈希分片
2
public class HashShardingStrategy {
3
    private static final int DB_COUNT = 4;    // 4个库
4
    private static final int TABLE_COUNT = 8; // 每库8张表
5

6
    // 计算库编号
7
    public int getDbIndex(Long userId) {
8
        return Math.abs(userId.hashCode()) % DB_COUNT;
9
    }
10

11
    // 计算表编号
12
    public int getTableIndex(Long userId) {
13
        return Math.abs(userId.hashCode()) % (DB_COUNT * TABLE_COUNT)
14
               / DB_COUNT;
15
    }
16

17
    // 获取完整表名
18
    public String getTableName(Long userId) {
19
        int dbIndex = getDbIndex(userId);
20
        int tableIndex = getTableIndex(userId);
21
        return String.format("db_%d.order_%d", dbIndex, tableIndex);
22
    }
23
}
24

25
// 使用示例
26
Long userId = 123456789L;
27
String tableName = strategy.getTableName(userId);
28
// 结果：db_1.order_3

电商订单表示例：

1
原表：order（10亿条数据）
2

3
分库分表后：
4
db_0: order_0, order_1, order_2, order_3
5
db_1: order_0, order_1, order_2, order_3
6
db_2: order_0, order_1, order_2, order_3
7
db_3: order_0, order_1, order_2, order_3
8

9
每个表约3000万条数据

2. 范围分片#

适用场景：时间序列数据、有明显冷热分离

1
// 按时间范围分片（按月）
2
public class RangeShardingStrategy {
3

4
    public String getTableName(Date orderTime) {
5
        SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM");
6
        String month = sdf.format(orderTime);
7
        return "order_" + month;
8
    }
9
}
10

11
// 表结构
12
order_202401  // 2024年1月订单
13
order_202402  // 2024年2月订单
14
order_202403  // 2024年3月订单
15
...

优点：

查询时间范围数据效率高
便于归档历史数据
扩容简单（新增月份表）

缺点：

数据分布可能不均匀（促销月订单激增）
热点问题（当月表压力大）

3. 地理位置分片#

1
// 按地区分片
2
public class GeoShardingStrategy {
3

4
    public String getDbName(String province) {
5
        // 华东、华南、华北、西南...
6
        String region = getRegion(province);
7
        return "db_" + region;
8
    }
9
}
10

11
// 适用于：
12
// - 同城配送订单
13
// - 区域性社交平台
14
// - O2O业务

4. 一致性哈希#

1
// 一致性哈希（便于扩容）
2
public class ConsistentHashStrategy {
3
    private TreeMap<Long, String> nodes = new TreeMap<>();
4

5
    public ConsistentHashStrategy() {
6
        // 添加虚拟节点
7
        for (int i = 0; i < 4; i++) {
8
            for (int j = 0; j < 150; j++) {
9
                long hash = hash("db_" + i + "_vnode_" + j);
10
                nodes.put(hash, "db_" + i);
11
            }
12
        }
13
    }
14

15
    public String getDbName(Long userId) {
16
        long hash = hash(userId.toString());
17
        Map.Entry<Long, String> entry = nodes.ceilingEntry(hash);
18
        return entry != null ? entry.getValue() : nodes.firstEntry().getValue();
19
    }
20
}

四、分片键选择原则#

关键要素#

考虑因素	说明	示例
查询频率	最高频的查询条件	用户查订单 →user_id
数据分布	确保数据均匀分布	✅user_id ❌ 性别
业务关联	相关数据在同一分片	订单+订单明细
扩展性	便于未来扩容	哈希 > 范围

电商场景示例#

订单表分片键选择：

1
// ❌ 不好的选择
2
// 1. 按订单状态分片 - 数据分布极不均匀
3
// 2. 按商品ID分片 - 查询"我的订单"需要扫描所有分片
4

5
// ✅ 好的选择
6
// 按用户ID分片
7
CREATE TABLE order_0 (
8
    order_id BIGINT,
9
    user_id BIGINT,     -- 分片键
10
    product_id BIGINT,
11
    order_time DATETIME,
12
    INDEX idx_user_id (user_id)
13
);
14

15
// 查询某用户订单：只查一个分片
16
SELECT * FROM order_X WHERE user_id = 123456;
17

18
// 查询某订单详情：订单ID中包含分片信息
19
// order_id = timestamp + user_id_hash + sequence

社交平台消息表：

1
// 按会话ID分片（保证对话消息在同一分片）
2
public String getShardKey(Long senderId, Long receiverId) {
3
    // 保证A→B和B→A的消息在同一分片
4
    Long small = Math.min(senderId, receiverId);
5
    Long large = Math.max(senderId, receiverId);
6
    return small + "_" + large;
7
}

五、常见问题与解决方案#

1. 跨分片查询#

问题：需要查询多个分片的数据

场景示例：

1
-- 查询最近7天所有订单（按user_id分片）
2
SELECT * FROM order
3
WHERE order_time > '2024-10-12'
4
ORDER BY order_time DESC
5
LIMIT 100;

解决方案：

方案 A：分散查询+结果合并

1
public List<Order> queryRecentOrders(Date startTime, int limit) {
2
    List<Future<List<Order>>> futures = new ArrayList<>();
3

4
    // 并行查询所有分片
5
    for (int i = 0; i < SHARD_COUNT; i++) {
6
        final int shardIndex = i;
7
        Future<List<Order>> future = executor.submit(() -> {
8
            String sql = String.format(
9
                "SELECT * FROM order_%d WHERE order_time > ? LIMIT %d",
10
                shardIndex, limit
11
            );
12
            return jdbcTemplate.query(sql, startTime);
13
        });
14
        futures.add(future);
15
    }
16

17
    // 收集结果
18
    List<Order> allOrders = new ArrayList<>();
19
    for (Future<List<Order>> future : futures) {
20
        allOrders.addAll(future.get());
21
    }
22

23
    // 内存排序+分页
24
    return allOrders.stream()
25
        .sorted(Comparator.comparing(Order::getOrderTime).reversed())
26
        .limit(limit)
27
        .collect(Collectors.toList());
28
}

方案 B：冗余设计（推荐）

1
// 订单表：按user_id分片
2
order_0, order_1, order_2, order_3
3

4
// 订单时间索引表：按时间分片
5
order_time_index_202410 {
6
    order_id,
7
    user_id,
8
    order_time
9
}
10

11
// 查询流程
12
1. 查时间索引表 → 获取order_id列表
13
2. 解析order_id → 定位具体分片
14
3. 批量查询订单详情

方案 C：搜索引擎

1
// 将订单数据同步到Elasticsearch
2
// 复杂查询走ES，简单查询走数据库
3

4
// Canal监听MySQL binlog → 实时同步到ES

2. 分布式事务#

问题：一个业务操作涉及多个分片

场景示例：转账

1
// 用户A（在db_0）转账给用户B（在db_1）
2
// 需要保证：A扣款、B加款 同时成功或失败

解决方案：

方案 A：避免分布式事务（最佳实践）

1
// 设计时避免跨分片操作
2
// 例如：电商订单
3
// - 订单表：按user_id分片
4
// - 订单明细表：按user_id分片（而非product_id）
5
// 这样创建订单时，主表和明细表在同一分片

方案 B：最终一致性（TCC）

1
// 转账示例 - TCC模式
2
public class TransferService {
3

4
    // Try：预留资源
5
    @Transactional
6
    public void tryTransfer(Long fromUser, Long toUser, BigDecimal amount) {
7
        // 冻结fromUser的金额
8
        accountDao.freeze(fromUser, amount);
9
        // 记录待入账
10
        accountDao.recordPending(toUser, amount);
11
    }
12

13
    // Confirm：确认提交
14
    @Transactional
15
    public void confirmTransfer(String txId) {
16
        // 扣除冻结金额
17
        accountDao.deduct(txId);
18
        // 实际到账
19
        accountDao.credit(txId);
20
    }
21

22
    // Cancel：回滚
23
    @Transactional
24
    public void cancelTransfer(String txId) {
25
        // 解冻金额
26
        accountDao.unfreeze(txId);
27
        // 取消待入账
28
        accountDao.cancelPending(txId);
29
    }
30
}

方案 C：Seata 分布式事务框架

1
@GlobalTransactional
2
public void createOrder(Order order) {
3
    // 1. 创建订单（db_0）
4
    orderService.create(order);
5

6
    // 2. 扣减库存（db_1）
7
    inventoryService.deduct(order.getProductId(), order.getQuantity());
8

9
    // 3. 扣减积分（db_2）
10
    pointService.deduct(order.getUserId(), order.getPoints());
11

12
    // Seata保证全部成功或全部回滚
13
}

方案 D：本地消息表

1
// 步骤1：本地事务 + 消息表
2
@Transactional
3
public void deductBalance(Long userId, BigDecimal amount) {
4
    // 扣款
5
    accountDao.deduct(userId, amount);
6

7
    // 写入消息表
8
    messageDao.insert(new Message(
9
        "ADD_BALANCE",
10
        toUserId,
11
        amount
12
    ));
13
}
14

15
// 步骤2：定时任务扫描消息表 → 发送MQ
16
// 步骤3：消费者处理加款
17
// 步骤4：更新消息状态为已完成

3. 全局唯一 ID 生成#

问题：分布式环境下如何生成唯一 ID

方案对比：

方案	优点	缺点	适用场景
Snowflake	性能高、趋势递增	依赖时钟	大部分场景
数据库号段	简单可靠	需要访问 DB	并发不高
Redis 自增	性能好	单点问题	配合主从
UUID	简单无依赖	无序、存储大	不推荐

Snowflake 实现：

1
public class SnowflakeIdGenerator {
2
    // 64位Long
3
    // 1位符号位 | 41位时间戳 | 10位机器ID | 12位序列号
4

5
    private final long workerId;
6
    private long sequence = 0L;
7
    private long lastTimestamp = -1L;
8

9
    public synchronized long nextId() {
10
        long timestamp = System.currentTimeMillis();
11

12
        if (timestamp < lastTimestamp) {
13
            throw new RuntimeException("Clock moved backwards!");
14
        }
15

16
        if (timestamp == lastTimestamp) {
17
            // 同一毫秒内，序列号递增
18
            sequence = (sequence + 1) & 0xFFF;
19
            if (sequence == 0) {
20
                // 序列号溢出，等待下一毫秒
21
                timestamp = waitNextMillis(lastTimestamp);
22
            }
23
        } else {
24
            sequence = 0L;
25
        }
26

27
        lastTimestamp = timestamp;
28

29
        return ((timestamp - EPOCH) << 22)
30
             | (workerId << 12)
31
             | sequence;
32
    }
33
}

4. 数据迁移与扩容#

平滑扩容方案：

1
// 从2个库扩容到4个库
2
// 原分片策略：userId % 2
3
// 新分片策略：userId % 4
4

5
// 步骤1：双写（新老库同时写入）
6
public void saveOrder(Order order) {
7
    // 写入老分片
8
    int oldShard = order.getUserId() % 2;
9
    oldDataSource[oldShard].save(order);
10

11
    // 同时写入新分片
12
    int newShard = order.getUserId() % 4;
13
    newDataSource[newShard].save(order);
14
}
15

16
// 步骤2：数据迁移（异步）
17
// 迁移历史数据到新分片
18

19
// 步骤3：读切流量
20
// 逐步将读流量切到新分片
21

22
// 步骤4：停止双写
23
// 完全切换到新分片，下线老分片

六、实战案例：电商订单系统#

架构设计#

1
// 1. 分片规则
2
- 订单表：按user_id哈希分片（4库32表）
3
- 订单明细表：按user_id分片（与订单表路由一致）
4
- 商家订单表：按shop_id分片（独立分片）
5

6
// 2. 表结构设计
7
CREATE TABLE order_0 (
8
    order_id BIGINT PRIMARY KEY,        -- Snowflake生成
9
    user_id BIGINT NOT NULL,            -- 分片键
10
    shop_id BIGINT NOT NULL,
11
    total_amount DECIMAL(10,2),
12
    status TINYINT,
13
    create_time DATETIME,
14
    update_time DATETIME,
15

16
    INDEX idx_user_time (user_id, create_time),
17
    INDEX idx_status (status, create_time)
18
) ENGINE=InnoDB;
19

20
// 3. 查询优化
21
// 用户查订单：带分片键，单分片查询
22
SELECT * FROM order_X
23
WHERE user_id = 123 AND create_time > '2024-01-01';
24

25
// 商家查订单：需要冗余商家订单表
26
CREATE TABLE shop_order (
27
    shop_id BIGINT,     -- 分片键
28
    order_id BIGINT,
29
    user_id BIGINT,
30
    create_time DATETIME,
31
    INDEX idx_shop_time (shop_id, create_time)
32
);
33

34
// 4. 统计报表
35
// 方案：订单数据 → Binlog → Kafka → Flink → OLAP数据库
36
// 报表查询不走在线库

关键代码#

1
@Service
2
public class OrderService {
3

4
    @Autowired
5
    private ShardingStrategy shardingStrategy;
6

7
    // 创建订单（单分片事务）
8
    @Transactional
9
    public Long createOrder(Order order) {
10
        // 生成订单ID
11
        long orderId = idGenerator.nextId();
12
        order.setOrderId(orderId);
13

14
        // 路由到分片
15
        String tableName = shardingStrategy.getTableName(order.getUserId());
16

17
        // 保存订单
18
        orderDao.save(tableName, order);
19

20
        // 保存订单明细（同一分片）
21
        for (OrderItem item : order.getItems()) {
22
            orderItemDao.save(tableName, item);
23
        }
24

25
        // 异步写入商家订单表
26
        shopOrderProducer.send(order);
27

28
        return orderId;
29
    }
30

31
    // 查询订单列表
32
    public List<Order> queryUserOrders(Long userId, int page, int size) {
33
        // 单分片查询
34
        String tableName = shardingStrategy.getTableName(userId);
35
        return orderDao.queryByUser(tableName, userId, page, size);
36
    }
37

38
    // 查询订单详情（通过order_id）
39
    public Order getOrderById(Long orderId) {
40
        // 从orderId中解析分片信息
41
        Long userId = parseUserIdFromOrderId(orderId);
42
        String tableName = shardingStrategy.getTableName(userId);
43
        return orderDao.getById(tableName, orderId);
44
    }
45
}

七、最佳实践总结#

设计原则#

能不拆就不拆：先优化 SQL、加缓存、读写分离
业务优先：根据业务特点选择分片策略
避免跨片：尽量让相关数据在同一分片
降级预案：准备好容灾和降级方案

技术选型#

中间件：ShardingSphere、MyCat、TDDL
ID 生成：Snowflake、美团 Leaf、滴滴 Tinyid
分布式事务：Seata、TCC、本地消息表

监控告警#

1
// 关键指标
2
- 各分片数据量分布
3
- 各分片QPS、RT
4
- 慢SQL监控
5
- 跨分片查询次数
6
- 分布式事务成功率

通过合理的分库分表策略，可以让数据库支撑从百万到数十亿级别的数据量，QPS 从几千提升到几十万。关键是要根据业务特点选择合适的方案,并做好监控和应急预案。

Libz's Blog