1. 亿级订单系统架构演进之路第一次看到订单表数据量突破千万级时我就意识到单库单表的架构已经走到尽头。查询响应时间从最初的200ms逐渐延长到2秒以上高峰期经常出现连接池耗尽的情况。作为核心业务系统这样的性能表现显然无法支撑业务发展。经过三个月的架构改造我们最终实现了日均百万级订单写入毫秒级单订单查询线性扩展的存储能力99.99%的系统可用性这套架构已经稳定运行两年期间经历了多次大促考验。今天我就把这次分库分表改造的完整方案和实战经验分享给大家。2. 架构改造核心思路2.1 问题诊断与解决路径当订单表数据量突破5000万后系统开始出现典型症状索引效率下降B树层级变深查询路径变长锁竞争加剧高频更新的状态字段成为热点备份耗时增长全量备份需要6小时以上表结构变更困难ALTER TABLE操作经常超时我们评估了三种解决方案方案优点缺点适用场景升级硬件实施简单有性能上限数据量增长缓慢读写分离缓解读压力写瓶颈仍在读多写少场景分库分表彻底解决扩展性问题改造成本高高并发大数据量最终选择分库分表方案主要基于以下考量业务持续高速增长需要长期解决方案现有QPS已达3000单机性能接近瓶颈未来三年预计订单量将达10亿级别2.2 技术选型对比我们重点对比了三种主流的分布式数据库方案2.2.1 原生分布式数据库以OceanBase为例-- 创建分区表示例 CREATE TABLE orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(32), user_id BIGINT, ... ) PARTITION BY HASH(id) PARTITIONS 64;优势原生支持分布式事务自动负载均衡完善的运维工具链劣势迁移成本高学习曲线陡峭厂商锁定风险2.2.2 中间件方案ShardingSphere-JDBC配置示例spring: shardingsphere: datasource: names: ds0,ds1 sharding: tables: orders: actual-data-nodes: ds$-{0..1}.orders_$-{0..31} table-strategy: inline: sharding-column: order_no algorithm-expression: orders_$-{order_no.hashCode() % 32} database-strategy: inline: sharding-column: user_id algorithm-expression: ds$-{user_id % 2}优势对应用透明可渐进式迁移社区生态丰富劣势分布式事务需要额外处理复杂查询性能较差2.2.3 云数据库方案如阿里云PolarDB-X-- 创建分片表示例 CREATE TABLE orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(32), user_id BIGINT, ... ) DBPARTITION BY HASH(user_id) TBPARTITION BY HASH(order_no) TBPARTITIONS 32;优势全托管服务弹性扩展能力兼容MySQL协议劣势成本较高功能限制较多最终我们选择了ShardingSphere-JDBC方案主要考虑技术栈延续性改造成本可控社区支持力度3. 核心实现细节3.1 分片键设计订单表的分片策略经过多次论证// 最终采用的分片算法 public class OrderShardingAlgorithm implements PreciseShardingAlgorithmString { Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueString shardingValue) { // 取订单号后4位用户ID进行分片 String orderNo shardingValue.getValue(); String userSuffix orderNo.substring(orderNo.length() - 4); int hash Math.abs(userSuffix.hashCode()); return orders_ (hash % 32); } }这样设计的好处保证同一用户的订单落在相同分片避免热点问题用户订单均匀分布支持高效的单用户订单查询3.2 分布式ID生成对比多种方案后我们采用改进版Snowflake算法public class OrderIdGenerator { private static final long USER_ID_BITS 12L; private static final long MAX_USER_ID ~(-1L USER_ID_BITS); public static String generate(long userId) { if (userId MAX_USER_ID) { userId userId % (MAX_USER_ID 1); } Snowflake snowflake new Snowflake(...); long id snowflake.nextId(); return String.format(%d%04d, id, userId); } }关键改进末尾追加4位用户ID便于分片计算支持字符串类型避免long溢出保留时间戳信息便于范围查询3.3 数据迁移方案采用双写增量同步的平滑迁移方案初始阶段老库单写开启binlog过渡阶段新老库双写Flink实时同步校验阶段数据一致性校验切换阶段读流量逐步切到新库收尾阶段停用老库写入Flink同步任务核心逻辑env.addSource(kafkaSource) .keyBy(Order::getOrderNo) .process(new OrderProcessFunction()) .addSink(jdbcSink); class OrderProcessFunction extends KeyedProcessFunctionString, Order, Order { Override public void processElement(Order oldOrder, Context ctx, CollectorOrder out) { // 数据清洗 Order newOrder convertOrder(oldOrder); // 分片路由计算 String tableSuffix shardingAlgorithm.doSharding(newOrder); newOrder.setTableSuffix(tableSuffix); out.collect(newOrder); } }4. 踩坑与优化记录4.1 分布式事务问题初期使用Seata时遇到的典型问题// 错误示例跨库事务 GlobalTransactional public void createOrder(Order order) { orderDao.insert(order); // 分片库1 inventoryDao.deduct(order); // 分片库2 pointsDao.add(order.getUserId()); // 分片库3 }优化方案将库存和积分操作改为异步消息本地事务表定时任务补偿最终一致性替代强一致性4.2 分页查询优化错误的分页实现SELECT * FROM orders WHERE user_id? ORDER BY create_time DESC LIMIT 10000, 20优化方案// 使用游标分页 public PageOrder queryByUser(Long userId, String lastOrderNo, int size) { return orderDao.query( SELECT * FROM orders WHERE user_id? AND order_no ? ORDER BY order_no DESC LIMIT ? , userId, lastOrderNo, size); }4.3 热点问题处理大促期间发现某些分片负载过高解决方案动态调整分片算法权重引入本地缓存减轻DB压力热点订单特殊处理// 热点订单缓存策略 Cacheable(cacheNames hotOrders, key #orderNo, cacheManager hotOrderCacheManager) public Order getByOrderNo(String orderNo) { return orderDao.selectByOrderNo(orderNo); }5. 性能对比数据改造前后关键指标对比指标改造前改造后提升写入QPS150080005倍查询延迟200ms50ms4倍可用性99.9%99.99%10倍扩容时间不可扩1小时-备份耗时6小时30分钟12倍6. 架构演进建议对于正在考虑分库分表的团队我的实践建议评估阶段先做垂直分表再考虑水平分片合理预估未来3-5年数据增长设计阶段分片键选择最频繁的查询条件避免跨分片事务和复杂join实施阶段灰度发布先切读流量再切写准备完善的回滚方案运维阶段建立完善的分片监控体系定期检查数据分布均衡性这套架构目前已经支撑日均百万级订单处理期间经历过多次大促考验。最大的体会是分库分表不是简单的技术选型而是需要从业务特点出发设计最适合的数据分布方案。