如何用阿里云oss+函数计算fc+事件总线EventBridge+消息队列+数据库+redis缓存打造一个高并发弹性系统？

构建一个类似 12306 高并发订票系统（高铁票务系统）是非常具有挑战性的场景：瞬时流量极高（如春运/节假日放票时每秒数十万请求）、数据一致性要求强（不能超卖）、响应延迟敏感。在这种场景下，单纯依赖传统架构很难扛住压力，而 阿里云的 Serverless + 事件驱动架构 可以作为核心组件，结合精心设计，构建高并发、弹性、可靠的系统。

目标：用阿里云构建一个类似 12306 的订票系统核心链路

注意：12306 官方系统极其复杂，本文聚焦于 “查余票 → 锁座 → 下单 → 支付” 的核心高并发路径，用阿里云组件实现弹性、防超卖、高可用。

一、整体架构设计（高并发订票核心链路）

[用户前端] 
   ↓（查余票 / 下单）
[API 网关] 
   ↓
[函数计算 FC] ←→ [Redis（缓存 + 分布式锁）]
   ↓（下单事件）
[EventBridge] → [RocketMQ]（削峰 + 解耦）
   ↓（异步消费）
[FC / ECS Worker] → [PolarDB（分布式数据库）]
                        ↑
                   [Redis 预加载余票]

关键点：热点数据缓存 + 库存预热 + 异步落库 + 分布式锁 + 限流熔断

二、核心模块详解

1. 余票查询：全走 Redis（禁止查 DB）

数据预热：

票务系统在放票前，将车次、座位、余票等数据提前加载到 Redis（集群版）。

使用 Hash 结构 存储：train:G101:date:20251207 → { seat_001: 1, seat_002: 0, ... }（1=可售，0=已锁/售出）

查询逻辑：

用户查票 → 直接查 Redis，不经过 DB。

Redis 设置 TTL + 主从 + 持久化 保证可用性。

优势：Redis QPS 可达 10w+，轻松应对查票高峰。

2. 下单流程：FC + Redis 分布式锁 + 消息队列

请求 → API 网关 → 函数计算 FC（下单函数）

# 伪代码
def handle_order(event):
    train_id = event['train']
    seat_id = event['seat']
    user_id = event['user']
    key = f"lock:{train_id}:{seat_id}"

    # 1. Redis 分布式锁（防并发超卖）
    if redis.set(key, user_id, nx=True, e...

点击查看剩余70%