一、架构设计与技术选型
典型分布式订单系统架构：
[网关层] → [订单服务] ←→ [分布式缓存]↑ ↓
[用户服务] [支付服务]↓ ↓
[MySQL集群] ← [分库分表中间件]
技术栈组合：
- Spring Boot 3.x
- Mybatis-Plus 3.5.x
- ShardingSphere 5.3.x
- Redis 7.x
- Seata 1.7.x
二、核心实现步骤
1. 订单表设计（分库分表场景）
CREATE TABLE t_order_0 (order_id BIGINT PRIMARY KEY COMMENT '雪花算法ID',user_id INT NOT NULL,amount DECIMAL(10,2) UNSIGNED,order_status TINYINT DEFAULT 0,create_time DATETIME DEFAULT CURRENT_TIMESTAMP,update_time DATETIME ON UPDATE CURRENT_TIMESTAMP,INDEX idx_user_status(user_id, order_status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
2. Mybatis-Plus增强配置
@Configuration
@MapperScan("com.orders.mapper")
public class MybatisConfig {@Beanpublic MybatisPlusInterceptor mybatisPlusInterceptor() {MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();// 分页插件interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));// 乐观锁插件interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor());return interceptor;}
}
3. 分库分表策略实现
# application-sharding.yml
spring:shardingsphere:datasource:names: ds0,ds1ds0: # 数据源配置ds1: rules:sharding:tables:t_order:actualDataNodes: ds${0..1}.t_order_${0..1}databaseStrategy:standard:shardingColumn: user_idshardingAlgorithmName: database-inlinetableStrategy:standard:shardingColumn: order_idshardingAlgorithmName: table-inlineshardingAlgorithms:database-inline:type: INLINEprops:algorithm-expression: ds${user_id % 2}table-inline:type: INLINEprops:algorithm-expression: t_order_${order_id % 2}
4. 订单服务核心实现
@Service
@Slf4j
public class OrderServiceImpl extends ServiceImpl<OrderMapper, Order> implements OrderService {@Autowiredprivate DistributedLockTemplate lockTemplate;@Transactional@GlobalTransactional // Seata分布式事务注解public Order createOrder(OrderDTO orderDTO) {// 幂等性检查String lockKey = "order_create:" + orderDTO.getRequestId();return lockTemplate.execute(lockKey, 3000, () -> {Order order = convertToEntity(orderDTO);baseMapper.insert(order);// 发送领域事件applicationContext.publishEvent(new OrderCreatedEvent(this, order));return order;});}@DS("slave") // 指定读从库public Page<OrderVO> queryOrders(OrderQuery query, Pageable pageable) {return baseMapper.selectPage(new Page<>(pageable.getPageNumber(), pageable.getPageSize()),Wrappers.<Order>lambdaQuery().eq(Order::getUserId, query.getUserId()).between(Order::getCreateTime, query.getStartTime(), query.getEndTime()).orderByDesc(Order::getCreateTime)).convert(this::convertToVO);}
}
5. Mybatis二级缓存优化
<!-- OrderMapper.xml -->
<cache type="org.mybatis.caches.redis.RedisCache" eviction="LRU"flushInterval="600000"size="1024"readOnly="true"/>
三、性能优化实践
- 热点订单缓存策略：
@Cached(name = "orderCache", expire = 30, timeUnit = TimeUnit.MINUTES)
public Order getOrderById(Long orderId) {return baseMapper.selectById(orderId);
}@CacheRefresh(refresh = 10, stopRefreshAfterLastAccess = 30, timeUnit = TimeUnit.MINUTES)
public Order getHotOrder(Long orderId) {// 高频访问订单特殊处理
}
- 批量操作优化：
public void batchInsertOrders(List<Order> orders) {String sql = "<script>INSERT INTO t_order (...) VALUES " +"<foreach collection='list' item='item' separator=','>" +"(#{item.userId}, ...)" +"</foreach></script>";sqlSessionTemplate.insert(sql, orders);
}
四、分布式事务解决方案对比
| 方案 | 一致性 | 性能影响 | 适用场景 |
|---|---|---|---|
| 本地事务 | 弱 | 无 | 单库操作 |
| XA协议 | 强 | 高 | 严格一致性金融交易 |
| TCC | 最终 | 中 | 高并发长事务 |
| SAGA | 最终 | 低 | 跨服务复杂业务流程 |
| 本地消息表 | 最终 | 中 | 异步可靠消息传递 |
五、生产环境注意事项
-
索引优化原则：
- 遵循最左前缀原则
- 避免在更新频繁的列建索引
- 使用覆盖索引减少回表
-
慢SQL监控配置：
mybatis-plus:configuration:log-impl: org.apache.ibatis.logging.slf4j.Slf4jImplmapUnderscoreToCamelCase: truedefault-executor-type: REUSEaggressive-lazy-loading: false# 开启SQL监控
spring:datasource:hikari:register-mbeans: true
- 数据归档方案：
@Scheduled(cron = "0 0 3 * * ?")
public void archiveOrders() {LocalDateTime archiveTime = LocalDateTime.now().minusMonths(6);baseMapper.archiveOrders(archiveTime);
}
六、监控与排查工具链
- 日志跟踪：SkyWalking + ELK
- SQL分析：Arthas + Mybatis-Plus性能分析插件
- 压测工具：JMeter + Gatling
- 可视化监控：Grafana + Prometheus
典型监控指标：
- 订单创建TPS
- 平均响应时间（P99）
- 慢SQL占比
- 缓存命中率
- 分库分表均衡度
实战总结：在Spring Boot分布式项目中实施订单管理，需要重点把握分库分表策略、缓存与数据库的协同、分布式事务的选型这三个核心维度。通过Mybatis-Plus的增强功能可以显著提升开发效率，同时要注意避免过度依赖ORM特性导致的性能问题。建议定期进行全链路压测，持续优化数据访问模式。