每年11月11日零点前后，全网的交易请求几乎同时涌进来。对电商平台来说，难点不只是订单多，而是几秒钟内，库存校验、支付回调和物流分配都要在毫秒级完成。双11从天猫的一次促销，变成了全行业的技术大考，系统承受的压力也一年比一年大。阿里云是阿里巴巴集团的基础设施底座，这些年承担了其中最核心的算力保障。
双11难在哪里
2009年，淘宝商城（今天猫）第一次做11月11日促销，当年成交额约5200万元。以当时的规模看，已经是不小的流量冲击。之后每年的增长，几乎都在顶破上一年的系统上限。流量往往集中在零点前后几分钟，平时那种按天、按小时慢慢扩容的办法，根本赶不上这种瞬时爆发。
技术团队碰到的麻烦大致有三类。一是高并发读写：商品详情页、购物车和库存扣减在同一时刻被大量访问，数据库很容易先顶不住。二是链路长：一笔订单从下单到支付完成，要经过十几个服务协同调用，哪一环超时，都可能拖垮整条链路。三是成本：如果照着峰值全年备货，大部分时间资源都在空转。
阿里云具体怎么做
针对这几类问题，阿里云的做法可以分成三块。
- 弹性伸缩：基于容器和弹性计算资源，活动前按预测自动扩容，活动结束后快速缩回去。没有这一步，闲置成本会很快吃掉大促的利润。
- 分布式数据库：通过分库分表和自研的分布式数据库，把读写压力分散到多个节点。拆分之后，跨库事务和数据一致性要重新设计，这一点不能省。
- 全链路压测：正式活动前，用接近真实的流量模型把整条交易链路跑一遍，提前找出性能瓶颈和依赖风险。
三者之间是互相牵着走的。压测暴露的问题，会决定扩容多少、数据库怎么拆；弹性调度又让压测能在接近真实的资源环境里反复做。大促保障能一年比一年稳，靠的就是这种循环。
一个大促准备的例子
下面这个例子是按行业常见做法整理的，不是某次活动的复盘，主要用来说明准备阶段该怎么走。假设某品牌商家在双11前两个月开始准备，先挑出最敏感的三个环节：商品库存、优惠券核销和支付回调。团队在云上搭了一套和生产环境一致的预发布集群，用历史订单生成压测脚本，把模拟流量逐步加到预估峰值的1.5倍。
压测时发现，库存服务在高并发下出现热点竞争，个别爆款商品的扣减请求排队很严重。处理办法是把热点库存拆到多个子账户分段扣减，同时加一层本地缓存，写库改成异步回写。调整后重新压测，接口平均响应时间降了一半多，峰值时段也稳住了。活动当天，扩容策略在零点前按预设规则完成资源扩展，高峰过去后，大部分实例又自动回收。
这个例子里，问题是在准备阶段暴露的，而不是活动当天才爆出来的。压测做得够不够，往往比当天的应急能力更能决定结果。
中小企业能借鉴什么
这些经验并不只适用于大平台。如果你的店铺或业务也有促销高峰，可以先从几件小事做起。
容量评估最好提前一到两周做，不要等活动前一天才想到扩容，那时候云上资源未必还有余量。下单、支付和库存是最不能出错的三条路，其他功能出了问题可以先降级，比如暂停推荐位或非核心的统计上报，先保住交易本身。用云服务的弹性能力时，按需付费就好，别为了一次高峰长期占着大量实例。压测也不必一上来就做全链路，哪怕只针对下单接口做一轮小规模验证，也能提前挡掉不少低级故障。
双11已经从一个购物节，变成检验数字基础设施能力的公开场景。阿里云做的，主要是把复杂的工程能力封装成可以复用的服务，让业务方能把精力放在经营本身。对准备数字化的企业来说，看懂这场大考背后的逻辑，比盯着峰值数字更有用。
