外卖平台每天1000万订单查询，是如何扛住高并发的？

沉默是金，总会发光

大家好，我是沉默

"我们系统每天有超过1000万笔订单查询，最近高峰时段响应开始变慢，怎么破？"

------这是一位外卖平台后台研发同学的真实反馈

这不是个例，几乎所有做电商、外卖的系统，都逃不过一个问题：读多写少的高频查询，怎么优化？

本篇文章，我将结合实战经验，从架构思路到关键代码，带你拆解我们是如何优化千万级订单查询接口的------稳定支撑高并发，P99 延迟控制在 100ms 以内，缓存命中率超过 90%。

**-**01-

问题分析

订单查询量级：

每天：10,000,000 次
每小时：416,666 次
每分钟：6,944 次
每秒钟：≈115 QPS（峰值可能达 1000+）

接口特点：

特征	说明
查询接口	GET `/api/order/{orderId}`
读多写少	95% 是读取
一致性要求高	状态必须实时准确（支付、配送等）
响应需迅速	用户/商家/客服频繁调用

这情况数据库是钢铁侠也扛不住，所以需要优化！

- 02-

优化目标与原则

目标：

高并发稳如狗，QPS 1000+ 不挂
P99 响应时间 < 100ms
一致性可控，状态不出错

设计原则：

读写分离：主库抗不住就放读库
冷热分离：新订单热、老订单冷，处理方式不同
缓存优先：Redis 缓 80%，DB 抗 20%
延迟一致：已完成订单异步归档，牺牲部分实时性换取系统稳定

- 03-

高并发架构怎么设计？

流程图：

arduino 复制代码

  Client     │     ▼API 网关（限流 + 监控）     │     ▼Redis 缓存（热点订单）     │ ┌───┴─────────────┐ │                 │ ▼                 ▼MySQL 主库    MySQL 历史库（归档）

查询优先级：

先查 Redis 缓存
缓存未命中 → 查主库
已完成订单 → 异步归档到历史库
定时清理 Redis 冷数据

**-**04-

关键代码案例

以下是 Spring Boot + MyBatis + Redis 的精简实现。

Redis 缓存配置

arduino 复制代码

@Configurationpublic class RedisConfig {    @Bean    public 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;    }}

查询主流程

vbnet 复制代码

@Servicepublic class OrderQueryService {    private static final String CACHE_KEY_PREFIX = "order:";    @Autowired    private RedisTemplate<String, OrderDTO> redisTemplate;    @Autowired    private 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());    }}

MyBatis Mapper

less 复制代码

@Mapperpublic interface OrderMapper {    @Select("SELECT * FROM orders WHERE id = #{id}")    Order selectById(@Param("id") Long id);}

**-**05-

还有哪些优化技巧？

缓存击穿保护

sql 复制代码

Double Check + 分布式锁（Redisson）防击穿

双层缓存（本地 + Redis）

Caffeine（本地毫秒级） + Redis（分布式共享）

3. 冷热数据分离

热订单（进行中）：保留在主库 & Redis
冷订单（已完成）：每天归档到历史库 + 清除缓存

**-**06-

如何压测效果？

使用 JMeter / Locust 模拟 1000 QPS，观察这些指标：

指标项	优化目标
Redis 命中率	> 90%
DB QPS 降低比	降低 80% 以上
P99 响应时间	< 100ms

总结：

系统优化，从来不是一招致胜，而是架构策略 + 缓存设计 + 数据分层 + 持续压测的组合拳。

千万级订单查询接口优化的经验告诉我们：

"你不能控制峰值有多猛，但你可以设计好如何扛住它。"

**-**07-

粉丝福利

点点关注，送你 SQL Server 性能调优实战，如果你正在优化 SQL，又或者刚准备调优性能。可以仔细阅读一下，或许对你有所帮助！