沉默是金，总会发光
大家好，我是沉默
“我们系统每天有超过1000万笔订单查询，最近高峰时段响应开始变慢，怎么破？”
——这是一位外卖平台后台研发同学的真实反馈
这不是个例，几乎所有做电商、外卖的系统，都逃不过一个问题：读多写少的高频查询，怎么优化？
本篇文章，我将结合实战经验，从架构思路到关键代码，带你拆解我们是如何优化千万级订单查询接口的——稳定支撑高并发，P99 延迟控制在 100ms 以内，缓存命中率超过 90%。
-01-
问题分析
订单查询量级：
- 每天：10,000,000 次
- 每小时：416,666 次
- 每分钟：6,944 次
- 每秒钟：≈115 QPS（峰值可能达 1000+）
接口特点：
特征 | 说明 |
查询接口 | GET |
读多写少 | 95% 是读取 |
一致性要求高 | 状态必须实时准确（支付、配送等） |
响应需迅速 | 用户/商家/客服频繁调用 |
这情况数据库是钢铁侠也扛不住，所以需要优化！
-02-
优化目标与原则
目标：
- 高并发稳如狗，QPS 1000+ 不挂
- P99 响应时间 < 100ms
- 一致性可控，状态不出错
设计原则：
- 读写分离：主库抗不住就放读库
- 冷热分离：新订单热、老订单冷，处理方式不同
- 缓存优先：Redis 缓 80%，DB 抗 20%
- 延迟一致：已完成订单异步归档，牺牲部分实时性换取系统稳定
-03-
高并发架构怎么设计？
流程图：
Client│▼
API 网关（限流 + 监控）│▼
Redis 缓存（热点订单）│┌───┴─────────────┐│ │▼ ▼
MySQL 主库 MySQL 历史库（归档）查询优先级：
- 先查 Redis 缓存
- 缓存未命中 → 查主库
- 已完成订单 → 异步归档到历史库
- 定时清理 Redis 冷数据
-04-
关键代码案例
以下是 Spring Boot + MyBatis + Redis 的精简实现。
1. Redis 缓存配置
@Configuration
public class RedisConfig {@Beanpublic RedisTemplate<String, OrderDTO> redisTemplate(RedisConnectionFactory factory) {RedisTemplate<String, OrderDTO> template = new RedisTemplate<>();template.setConnectionFactory(factory);template.setKeySerializer(new StringRedisSerializer());template.setValueSerializer(new Jackson2JsonRedisSerializer<>(OrderDTO.class));return template;}
}2. 查询主流程
@Service
public class OrderQueryService {private static final String CACHE_KEY_PREFIX = "order:";@Autowiredprivate RedisTemplate<String, OrderDTO> redisTemplate;@Autowiredprivate OrderMapper orderMapper;public OrderDTO getOrderById(Long orderId) {String cacheKey = CACHE_KEY_PREFIX + orderId;// Step 1: Redis 缓存查询OrderDTO cached = redisTemplate.opsForValue().get(cacheKey);if (cached != null) return cached;// Step 2: DB 查询Order order = orderMapper.selectById(orderId);if (order == null) throw new OrderNotFoundException(orderId);OrderDTO dto = convert(order);// Step 3: 写入缓存，设 5 分钟过期redisTemplate.opsForValue().set(cacheKey, dto, Duration.ofMinutes(5));return dto;}private OrderDTO convert(Order order) {return new OrderDTO(order.getId(), order.getStatus(), order.getAmount(), order.getCreatedAt());}
}3. MyBatis Mapper
@Mapper
public interface OrderMapper {@Select("SELECT * FROM orders WHERE id = #{id}")Order selectById(@Param("id") Long id);
}-05-
还有哪些优化技巧？
1. 缓存击穿保护
Double Check + 分布式锁（Redisson）防击穿2. 双层缓存（本地 + Redis）
Caffeine（本地毫秒级） + Redis（分布式共享）3. 冷热数据分离
- 热订单（进行中）：保留在主库 & Redis
- 冷订单（已完成）：每天归档到历史库 + 清除缓存
-06-
如何压测效果？
使用 JMeter / Locust 模拟 1000 QPS，观察这些指标：
指标项 | 优化目标 |
Redis 命中率 | > 90% |
DB QPS 降低比 | 降低 80% 以上 |
P99 响应时间 | < 100ms |
总结：
系统优化，从来不是一招致胜，而是架构策略 + 缓存设计 + 数据分层 + 持续压测的组合拳。
千万级订单查询接口优化的经验告诉我们：
“你不能控制峰值有多猛，但你可以设计好如何扛住它。”
-07-
粉丝福利
点点关注，送你 SQL Server 性能调优实战，如果你正在优化 SQL，又或者刚准备调优性能。可以仔细阅读一下，或许对你有所帮助！
