订单系统抗大促架构演进:异步削峰、库存预扣、服务拆分与最终一致性

那年第一次参加大促,我们的订单系统在活动开始后第四分钟就崩了。监控大屏上,下单接口的成功率从 99% 直线跳水到不足 30%,数据库的连接数瞬间打满,CPU 飙到 100% 趴在那儿不动,紧接着连商品详情、购物车这些跟下单八竿子打不着的页面也开始转圈——因为它们和订单共用一个数据库,被一起拖下了水。更糟的是,事后清点发现有上百个订单库存超卖了,得连夜人工退款道歉。那一晚我们守在电脑前手动重启、扩容、改配置,折腾到凌晨三点才勉强稳住。

复盘会上结论很清楚:不是机器不够,是架构扛不住这种瞬时洪峰。一个平时跑得好好的同步串行单体,在大促这种"平时十倍流量在几秒内灌进来"的场景下,每一个同步等待、每一处共享资源,都会被放大成压垮系统的那根稻草。接下来一年多,我们把这套订单系统从那个一推就倒的单体,一步步演进成了能削峰、能隔离、能降级、出了岔子还能自动对平的架构。这篇就把这条演进路线完整记下来:每一步是被什么问题逼出来的、怎么改的、解决了什么又带来了什么新问题。

起点:一个同步串行的单体为什么一推就倒

先看看最初的下单是怎么跑的。用户点"提交订单",一个请求进来,在同一个线程里同步地、一步接一步地做完所有事:校验参数 → 查库存 → 扣库存 → 创建订单 → 调支付 → 发消息通知 → 返回。这七步全串在一条调用链上,任何一步慢,整个请求就一直占着线程和数据库连接等在那儿。

问题的本质有三个:一是同步串行,把可以晚点做、可以并行做的事全堆在用户等待的关键路径上;二是资源共享,订单和其他业务挤同一个库,一损俱损;三是没有任何缓冲,洪峰流量直接砸到数据库这个最脆弱、最难扩容的环节上。后面每一步演进,都是在拆解这三个问题中的一个。

演进一:异步削峰,给洪峰加一个蓄水池

第一刀砍向"洪峰直击数据库"。大促的流量特征是瞬时极高、但总量可控——一秒涌进来几万个下单请求,但系统其实有能力在接下来一两分钟内慢慢把它们处理完,只是受不了"全在同一秒砸过来"。这正是消息队列削峰填谷的经典场景:在用户和数据库之间架一个队列当蓄水池,请求进来先快速落到队列里就立刻给用户返回"下单处理中",真正的扣库存、写订单由后端消费者按数据库扛得住的速率匀速地从队列里取出来处理。

// 下单接口:不再同步落库,而是校验后快速入队就返回
@PostMapping("/order/submit")
public Result submit(@RequestBody OrderRequest req) {
    // 1. 只做轻量的同步校验(参数、登录态、风控)
    validate(req);
    // 2. 生成订单号并把下单消息投递到队列,立刻返回
    String orderNo = idGenerator.next();
    OrderMessage msg = OrderMessage.of(orderNo, req);
    mq.send("order_create_topic", msg);   // 投递成功即返回,不等落库
    // 3. 给用户一个"处理中"的受理回执,前端轮询/推送拿最终结果
    return Result.accepted(orderNo);
}

// 消费者:按数据库扛得住的速率匀速消费,把洪峰摊平成平稳水流
@RabbitListener(queues = "order_create_queue", concurrency = "20")
public void consume(OrderMessage msg) {
    deductStock(msg);      // 扣库存
    createOrder(msg);      // 写订单
    // 后续支付、通知再各自异步触发
}

这一步把"用户感知的下单耗时"从数秒压回了几十毫秒(只剩校验 + 入队),数据库再也不用直面瞬时洪峰——无论前面涌进来多少,后端消费者永远按固定并发匀速处理。架构从"洪峰直击"变成了"洪峰入池、匀速出水",画出来对比非常直观:

但异步不是免费的午餐,它立刻带来两个新问题:一是用户拿不到"立即下单成功"的同步结果了,得改成受理回执 + 异步通知最终结果;二是数据一致性从"强一致"滑向了"最终一致"——消息可能投递失败、消费可能出错,订单状态会有一小段时间是悬空的。这两个问题,后面的演进会专门去填。架构演进就是这样:每解决一个老问题,几乎都会引入一个新问题,关键是确保新问题比老问题更可控、更好治。

演进二:库存预扣,用 Redis 原子操作堵住超卖

异步削峰解决了"数据库被打满",但那次大促上百个超卖订单的账还没还。超卖的根源是查库存和扣库存之间存在竞态:两个请求几乎同时读到"库存还剩 1",于是都认为可以下单,结果都扣成功,库存变成 -1。在同步串行时这靠数据库行锁勉强兜着,但行锁在热点商品上会让请求排长队、慢得要命;异步化之后消费者并发消费,竞态窗口反而更大了。

对策是把库存判断和扣减前移到 Redis,并用一段 Lua 脚本把"判断 + 扣减"做成一个原子操作。Redis 单线程执行 Lua,天然保证脚本内的多步操作不会被其他请求插队,从根上消除了竞态。下单请求在入队前先在 Redis 里预扣库存,扣减失败(库存不足)直接拦在最前面,连队列都不用进:

-- deduct_stock.lua:判断库存是否充足 + 扣减,整体原子执行
local key = KEYS[1]
local need = tonumber(ARGV[1])
local stock = tonumber(redis.call('GET', key))
if stock == nil then
    return -1            -- 库存未初始化
end
if stock < need then
    return 0             -- 库存不足,扣减失败
end
redis.call('DECRBY', key, need)
return 1                 -- 扣减成功

// 入队前先在 Redis 预扣,挡住卖超的请求
public Result submit(OrderRequest req) {
    Long ok = redis.execute(deductStockScript,
                            List.of("stock:" + req.getSkuId()),
                            String.valueOf(req.getQty()));
    if (ok != 1L) {
        return Result.fail("已抢光");   // 库存不足,直接拒绝,不进队列
    }
    // 预扣成功才入队,后端消费时再把 DB 库存与 Redis 对齐
    mq.send("order_create_topic", OrderMessage.of(idGenerator.next(), req));
    return Result.accepted();
}

这一招把超卖彻底堵死了:Redis 预扣是整个下单流程的第一道闸,卖超的请求在这里就被原子地挡回去,根本到不了数据库。同时它还顺手做了流量过滤——大促时大量"来抢但没抢到"的请求在 Redis 这层就被快速拒绝了,真正能进队列、要写库的请求数量被库存总量天然限定住,后端压力进一步可控。代价是要维护 Redis 与数据库库存的一致性(预扣成功但最终下单失败时要回补 Redis 库存),这又是一笔最终一致性的账,记下,稍后一起算。

演进三:服务拆分,让一个模块的故障别拖垮全场

前两步把核心下单链路救活了,但还有个隐患没除:那次崩溃时,商品详情、购物车页面也跟着挂了,只因为它们和订单挤在同一个单体、共用同一个数据库连接池。故障的传染性,本质是因为没有边界——所有模块共享资源,一处资源被耗尽,全盘陪葬。要止血,就得给关键业务划出独立的资源边界。

我们按业务把单体拆成了几个独立部署的服务:订单、库存、支付、用户各自独立,有各自的数据库、各自的连接池、各自的部署实例。这样下单服务即便被打满,商品浏览这些只读、高频的服务完全不受影响,用户至少还能正常逛、正常加购物车,不至于整站瘫痪。拆分时最重要的原则是按业务能力的边界拆,而不是按技术分层拆,并且让服务间只通过明确的接口通信、绝不共享数据库:

# 拆分后每个服务独立资源,故障被隔离在服务边界内
services:
  order-service:      # 下单:写密集,大促压力最大
    replicas: 8
    db: order_db      # 独立库,连接池打满也只影响下单
    deploy: { cpu: "2", memory: 4Gi }
  inventory-service:  # 库存:对接 Redis 预扣 + DB 对齐
    replicas: 4
    db: inventory_db
  product-service:    # 商品:只读高频,和下单完全隔离
    replicas: 6
    db: product_db    # 即便下单挂了,逛商品照样顺畅
  payment-service:    # 支付:对接外部,需独立的超时与熔断
    replicas: 4
    db: payment_db

拆分带来的好处立竿见影:资源隔离让故障不再全站传染,各服务还能按自身压力独立扩容——大促时只需把压力最大的订单服务从 8 个实例临时扩到 30 个,而不必把整个单体连同那些根本不缺资源的模块一起傻扩。当然,拆分也把"本地方法调用"变成了"跨网络的服务调用",引入了网络延迟、调用失败、分布式事务等一系列新课题——这正是为什么前面那些异步、超时、一致性的功课必须补齐:拆分微服务不是银弹,它用"治理分布式系统的复杂度"换来了"故障隔离和独立伸缩的能力",这笔交易值不值,取决于你是否真的需要后者。

演进四:最终一致性,用本地消息表把悬空的状态对平

异步和拆分一路欠下的"一致性账",到这里必须还了。最典型的坑是"写订单"和"发消息"这两件事没法保证同时成功:订单库里订单写成功了,但紧接着投递"去支付/去发货"的消息时进程挂了,消息没发出去——于是这个订单永远卡在"已创建未支付"的悬空状态,用户付了钱却迟迟不发货,或者库存被预扣了却没有对应订单。反过来,先发消息再写订单,又可能消息发了订单没写成。这是分布式系统里经典的"双写一致性"难题。

我们用的是本地消息表(也叫事务消息)方案,核心思想是:把"写业务数据"和"记一条待发消息"放进同一个本地数据库事务里,让它们要么一起成功、要么一起回滚,从而保证"只要订单写成功了,待发消息就一定也记下来了"。消息是否真的投递出去,则交给一个后台任务去轮询补偿——发出去了就标记完成,没发出去就重试,直到成功:

// 写订单 + 记消息,放在同一个本地事务里,保证两者原子
@Transactional
public void createOrder(OrderMessage msg) {
    orderMapper.insert(toOrder(msg));        // 1. 写业务数据
    localMsgMapper.insert(new LocalMessage(  // 2. 同事务记一条待发消息
        msg.getOrderNo(), "pay_topic", toJson(msg), "PENDING"));
    // 两条 SQL 同事务:要么都成功,要么都回滚,绝不会"订单写了消息丢了"
}

// 后台补偿任务:轮询未发送的消息,投递成功才标记完成,失败下轮重试
@Scheduled(fixedDelay = 3000)
public void relayMessages() {
    for (LocalMessage m : localMsgMapper.findPending(200)) {
        try {
            mq.send(m.getTopic(), m.getPayload());
            localMsgMapper.markSent(m.getId());        // 投递成功,置为已发送
        } catch (Exception e) {
            localMsgMapper.incrRetry(m.getId());        // 失败累加重试次数,下轮再来
        }
    }
}

这套机制下,消息投递从"可能丢"变成了"至少投递一次(at-least-once)"——也正因为"至少一次",消费端必须做幂等:同一条消息可能因为补偿重试被投递多次,消费者要靠订单号这样的业务唯一键去重,保证"扣两次库存""发两次货"这种事不会发生。整条链路最终达到的是最终一致:某个瞬间状态可能是悬空的,但系统保证在有限时间内、靠补偿任务把它对平。分布式下没有免费的强一致,能做的是把不一致的窗口收窄到可接受的范围,并保证它一定会被自动收敛,而不是放任它永久悬空。

除了本地消息表,我们还加了一道每日对账兜底:对比 Redis 预扣库存、订单表、支付流水三方的数据,把任何对不上的记录捞出来人工或自动修复。补偿任务管"实时收敛",对账管"兜底排查",两道防线叠起来,才敢说这套异步架构的数据是可信的。

演进五:限流降级,给系统留一条活路

前面四步让系统能扛住"预期内的大促洪峰",但总有"超出预期"的时刻——流量比预估的还高一截,或者某个下游(比如支付)突然抽风。这时候不能让系统硬扛到崩,而要主动丢弃一部分、保住核心的大部分,这就是限流和降级。限流是在入口处给流量设个闸,超过系统容量的请求直接快速拒绝(给用户"排队中,请稍后重试"),而不是放进来一起拖垮系统;降级则是在系统吃紧时,主动关掉非核心功能(如积分、推荐、详情页的花哨模块),把宝贵的资源全留给下单、支付这些核心链路。

# Sentinel 风格的限流 + 降级规则
flow-rules:
  - resource: /order/submit       # 下单接口入口限流
    grade: QPS
    count: 5000                   # 超过 5000 QPS 的请求快速失败,不放进来拖垮后端
    controlBehavior: reject

degrade-rules:
  - resource: payment-service     # 支付下游慢/错率高时熔断,走降级
    grade: SLOW_REQUEST_RATIO
    count: 1.0                    # 响应超 1s 算慢
    slowRatioThreshold: 0.5       # 慢调用占比超 50% 触发熔断
    timeWindow: 10                # 熔断 10s 后半开试探恢复

fallback:
  recommend-service: "返回缓存的兜底推荐"   # 非核心服务降级:挂了就返回兜底数据
  point-service: "异步补记,下单不阻塞"       # 积分非核心:出错不影响主流程

限流和降级的设计哲学,是承认资源永远是有限的,与其在过载时全盘崩溃、所有人都用不了,不如有策略地舍弃一部分,让大多数人的核心操作还能成功。大促时我们宁可让一小部分用户看到"排队中请重试",也绝不能让整个下单链路再像第一年那样彻底瘫痪。配合前面的熔断,某个下游故障时能被快速隔离、走降级兜底,而不是让调用方线程全堆在那儿等超时、最终雪崩。一个成熟的系统,不是追求"永不拒绝任何请求",而是追求"在任何压力下都还能提供有损但可用的核心服务"。

五步演进的累计效果

把这条演进路线摊在一张表上,能很清楚地看到每一步分别治的是什么病、又欠下了什么新账——而后面的步骤往往正是在还前面的账:

第二年的大促,同样量级甚至更高的流量打过来,下单成功率稳在 99% 以上,数据库负载平稳,没有一例超卖,商品浏览全程顺畅,我们几个人喝着茶看监控曲线就把活动平稳送过去了——和第一年凌晨三点的手忙脚乱,恍如两个世界。

要不要走这套演进?照这棵树判断

必须强调:这套架构不是拿来无脑套用的。它每一步都在用复杂度换某种能力,如果你没有对应的问题,引入它就是徒增维护负担。我把"该不该上某一步"的判断逻辑整理成一棵决策树:

我们沉淀下来的几条架构原则

这趟演进走完,下面几条进了团队的架构评审清单,新系统设计时一律对照检查:

1. 关键路径只留必须同步的事:能异步的(通知、积分、统计)全部移出用户等待链路。
2. 洪峰前面要有缓冲:别让瞬时流量直击数据库这种最难扩容的环节,用队列削峰。
3. 并发争抢用原子操作:超卖、扣减这类竞态,靠 Redis Lua 或数据库原子语义解决,别用"查了再改"。
4. 按业务边界划资源:核心业务独立库、独立连接池、独立部署,故障隔离在边界内。
5. 异步必配幂等:只要消息可能重复投递,消费端就必须用业务唯一键去重。
6. 一致性靠收敛而非强求:本地消息表 + 补偿管实时收敛,对账兜底,允许短暂不一致但保证最终对平。
7. 过载要能有损可用:入口限流 + 核心/非核心分级降级,绝不让系统硬扛到全盘崩溃。

几个走演进时容易踩的误区

这套思路分享给其他团队时,我发现有几个误区特别常见,这里专门点出来。

第一个误区是一上来就奔着微服务去,盲目拆分。有团队系统才几千日活,就照着大厂架构拆了十几个微服务,结果一个简单功能要改五个服务、联调到崩溃,分布式事务、链路追踪、服务治理的复杂度全砸到几个人头上,得不偿失。架构是被真实问题逼出来的,不是照着别人的终态抄出来的。我们也是先有了"被打垮"的痛,才一步步演进的——没有那个痛,单体其实挺好。

第二个误区是异步化后忘了补一致性和幂等。很多人享受了异步削峰的爽,却没意识到它把强一致换成了最终一致,既没做本地消息表防丢消息,也没做幂等防重复消费,结果偶发的丢单、重复发货比同步时代还难查。异步的复杂度不会消失,只会从"用户等待"转移到"数据一致性",这笔账迟早要还。

第三个误区是限流降级只在文档里、从不演练。限流阈值拍脑袋定、降级开关上线后从没真正切过,等真出事那一刻才发现阈值离谱、降级开关早就失效了。这些兜底手段必须靠定期的压测和故障演练去校准,平时不练,关键时刻就是摆设。容灾能力是练出来的,不是配置出来的。

写在最后

回头看这套订单系统的演进,我最深的体会是:好的架构不是一开始就设计得多完美,而是能随着压力的增长,有方向、有节奏地长出该长的能力。从同步单体到异步削峰、库存预扣、服务拆分、最终一致、限流降级,每一步都不是凭空炫技,而是被一个具体的、活生生的痛点逼出来的;每一步在解决老问题的同时也诚实地引入了新问题,而下一步往往就是在还上一步的账。

所以如果你的系统还没遇到那个"被打垮的夜晚",不必急着把这些都堆上去——单体清晰、好维护,本身就是巨大的价值。但当压力真的来临、老办法开始失灵时,希望这条演进路线能给你一张地图:先看清痛在哪个环节,再针对性地长出对应的能力,一步一步,把一个一推就倒的系统,熬成一个推不倒、压不垮、出了岔子还能自己对平的系统。架构演进从来没有终点,它只是跟着业务一起,不断地长大而已。

—— 别看了 · 2026