每年春运前后，12306 总会被拿出来说一遍。开票或临近出行的那几分钟，查询和下单请求会一下子涌进来，峰值可能远高于平日。这种瞬时高峰对任何在线系统都很难应付。票务系统有两件事必须同时做好：票不能超卖，页面也不能长时间打不开。两个目标放在一起，架构上就不轻松。
很多人第一反应是多加服务器。但服务器是固定成本，春运高峰只有几周，其余时间大部分资源都闲着，账算不过来。更合理的思路是让资源跟着负载走，高峰时多开，低谷时收回，这正是公有云想解决的问题之一。
需要说明的是，12306 的内部架构并没有完整公开，下面讨论的是这类票务系统的通用做法，不代表它的实际部署。
弹性伸缩能帮什么，又帮不了什么
阿里云这类公有云平台的核心能力之一是弹性计算和资源调度。系统可以根据实时负载自动增加或减少计算实例。平时保持较小规模，成本可控；高峰来临时，在短时间内扩到所需节点数，流量回落后再释放。
举个假设的例子。某省级票务查询服务平时请求量比较平稳，节假日前一周，查询量会在短时间内明显上涨。如果伸缩策略只看 CPU，反应往往偏慢，所以更常见的做法是把 CPU 利用率和请求队列长度一起作为扩容依据。另外，实例从拉起到能接流量需要一段时间，提前预热，比高峰时临时扩容稳得多。
但弹性扩容解决不了所有问题。假如数据库只有一个节点，应用层扩到再多，压力最终还是落在数据库上。所以弹性伸缩一般要和下面几类手段配合使用。
分层削峰：别让每个请求都打到数据库
成熟的票务系统通常会按层处理请求。最外层是静态资源和页面缓存，车次、站点、时刻表这类变化少的数据放在 CDN 或边缘节点，刷新页面时不必每次回源。中间一层是缓存，比如 Redis 集群，用来承接余票查询这类读多写少的请求。涉及库存扣减和订单生成的交易核心，才需要走强一致的路径。
实际设计中，常见的几种手段包括：
- 排队机制：超出处理能力的请求进入队列，按顺序放行，避免瞬间并发把后端压垮。队列要设置上限和超时，否则排队本身会变成新的堆积。
- 限流降级：对异常流量设阈值，超出部分返回明确提示，比如“当前访问人数较多，请稍后再试”，而不是让整个服务一起超时。
- 读写分离：查询走只读副本，下单走主库。余票刷新量再大，也不至于拖慢交易写入。但副本存在延迟，用户看到的余票可能比真实库存略旧，页面上要有相应的处理。
- 异步处理：订单创建成功后，通过消息队列通知支付、短信等下游服务。主链路只做必要的事，下游变慢或故障时，也不会拖住下单。
阿里云的消息队列、云数据库、负载均衡等产品基本能覆盖上面的环节。团队可以按需组合，不必每个模块都从零自研，但组合方式仍要结合自己的业务来定。
超卖问题：抢票系统最不能松的地方
抢票场景里最容易出问题的是超卖。库存扣减逻辑如果存在并发漏洞，同一张票可能被两个人同时确认，这在业务上后果很重。常见做法是在数据库层使用乐观锁或带条件的原子更新，比如只有剩余库存大于零时才允许扣减，并通过事务保证扣减和订单写入要么同时成功，要么同时回滚。
跨地域部署时，还要考虑数据同步延迟和异地多活的复杂度。云平台一般提供多可用区能力，单个机房出故障时，可以把流量切到另一个可用区，缩小影响范围。但切换流程需要定期演练。没演练过的切换，真出事时很可能手忙脚乱，甚至比不切换更糟。
高峰前的准备，往往比架构图更关键
很多团队会在春运前做全链路压测，用模拟流量逐层检验承载能力，同时确认监控告警、日志检索和应急预案都能正常工作。压测的价值不只是证明系统能扛住，更在于提前找出哪个环节最先撑不住。
容量规划要留足余量，还要提前和云厂商确认资源配额。如果高峰到来时配额已经用完，再好的弹性策略也扩不出实例。这些细节看上去琐碎，但一次高峰是平稳度过还是出故障，常常就取决于它们。
小结
回到标题的问题，阿里云这类弹性基础设施确实提供了扩容能力，但能不能扛住，取决于整套设计。弹性伸缩负责让资源跟上峰值，分层缓存和限流负责挡住无效压力，一致性设计负责守住库存底线，演练则负责在真正高峰前暴露问题。其中任何一环缺失，都可能在高峰时出问题。
