回答

搭建一个类似 12306 的高并发、海量数据、业务极其复杂的抢票系统，是软件架构设计中的“珠穆朗玛峰”。

这不仅仅是一个技术问题，更是一个资源博弈、流量削峰、数据一致性的综合工程。

以下我将从核心挑战、总体架构、关键技术点、数据库设计四个维度，为您还原一套可落地的架构方案。

一、 核心挑战 (The Challenges)

流量瞬时峰值极高：春节抢票期间，QPS（每秒查询率）可能达到几百万，TPS（每秒下单量）几十万。

读写比例悬殊：查询请求是下单请求的成百上千倍（Read >> Write）。

库存扣减复杂：火车票不是简单的 库存-1。买“北京-上海”的票，意味着“北京-济南”、“济南-南京”、“南京-上海”这些区间的票都要被占用。

不能超卖：这涉及到底层数据的一致性，绝对不能两个人买到同一个座位。

防黄牛/机器人：90% 的请求可能来自脚本，系统必须能识别并拦截。-

二、 总体架构设计 (Architecture Layers)

采用 “漏斗型” 流量过滤架构，层层拦截，保证最后打到数据库的请求是极少数有效的。

1. 客户端层 (Client)

静态资源 CDN 加速：JS, CSS, 图片全部上 CDN，减轻源站压力。

智能降级：如果后端崩了，APP端直接显示“排队中”，而不是白屏。

2. 网关与安全层 (Gateway & Security)

验证码系统：这是第一道防线。复杂的图形验证码、滑块，强制人机交互，挡住 90% 的脚本。

限流熔断 (Sentinel/Hystrix)：针对 IP、用户 ID 进行限流。超过阈值直接返回“系统繁忙”。

LVS + Nginx：做负载均衡，将流量分发到下游集群。

3. 服务层 (Microservices)

查询服务：纯内存操作，抗住 99% 的流量。

订单服务：处理排队、下单逻辑。

库存服务：负责核心的扣减逻辑。

4. 数据层 (Data & Cache)

本地缓存 (Guava/Caffeine)：应用服务器内部缓存。

分布式缓存 (Redis Cluster)：核心抗压层。

消息队列 (RocketMQ/Kafka)：削峰填谷，异步处理。

数据库 (MySQL/TiDB)：分库分表，作为兜底存储。

三、 关键技术解决方案

1. “余票查询”设计 (如何抗住百万 QPS?)

核心思想：查询绝对不能查数据库！

多级缓存策略：

L1 浏览器缓存：缓存 3-5 秒，防止用户疯狂刷新。

L2 本地缓存 (JVM)：在服务器内存中缓存热门车次信息，减少网络开销。

L3 Redis 缓存：存储车次基础信息、余票数量。

缓存预热：在放票前 5 分钟，将热门车次数据加载进 Redis。

读写分离：余票数是允许短暂不一致的（显示有票，点进去没了是可以接受的），可以使用 Redis 的读写分离。

2. “下单与扣库存”设计 (最核心难点)

核心思想：异步处理 + Redis 原子操作。

流程：

请求拦截：用户点击“提交订单”，网关拦截，校验 Token，限流。

Redis 预扣减 (Lua 脚本)：

这是防止超卖的关键。利用 Redis 单线程特性和 Lua 脚本的原子性。

脚本逻辑：检查该车次、该区间是否有票？有 -> decr 扣减 -> 返回成功；无 -> 返回失败。

注意：这里扣的是“缓存中的库存”，不是数据库。

排队系统 (MQ)：

Redis 扣减成功后，生成一个“排队号”，将订单信息扔进 RocketMQ。

立即给用户返回：“系统正在处理中，您排在第 125 位...”。

前端轮询查询订单状态。

异步落库：

消费者服务从 MQ 拉取订单，进行真正的数据库 Insert 操作。

如果数据库扣减失败（极小概率），回滚 Redis 库存。

3. 库存数据结构设计 (位运算黑科技)

火车票库存不是简单的数字，因为涉及 区间。假设 A -> B -> C -> D 四个站。

买 A->D 的票，必须 A->B, B->C, C->D 都有座。

使用二进制位图 (Bitmap) 优化：假设一趟车有 10 个站，可以用 10 bit 表示。

0 表示未占用，1 表示占用。

下单 A->C (即第1站到第3站)：将对应位设置为 1。

Redis 中通过 BITFIELD 或自定义二进制运算进行极速判断和扣减。

4. 数据库分库分表 (Sharding)

单表数据量过亿查询会极慢。

分库：按业务分（用户库、订单库、车次库）。

分表：

订单表：按 User_ID 取模分表，方便用户查自己的订单。

同时建立索引表（Elasticsearch 或 HBase），按 Date 或 Train_ID 分片，方便后台查询和大数据分析。

四、 极端情况的兜底 (Plan B)

流量隔离 (Bulkheading)：

将“查票”和“下单”服务物理隔离。哪怕下单服务挂了，用户起码还能查票。

核心业务（购票）与非核心业务（广告、会员）隔离。

热点隔离：

识别热门车次（如北京-哈尔滨），将其分发到独立的、性能更强的服务器集群，防止拖垮整个系统。

同城双活/异地多活：

北京机房挂了，流量自动切到上海机房。这需要极强的数据同步能力（通常基于底层数据库的 binlog 同步）。

五、 简化的代码逻辑演示 (Redis Lua 扣减)

这是防止超卖的核心代码片段（伪代码）：

-- keys[1]: 车次座位 Key (e.g., "ticket:G1024:20231001")
-- argv[1]: 需要扣减的区间位掩码 (e.g., 二进制 0110 代表占用了中间两站)

local key = KEYS[1]
local mask = tonumber(ARGV[1])

-- 1. 获取当前座位状态
local current_seat_status = tonumber(redis.call('get', key) or "0")

-- 2. 通过位运算判断是否有冲突
-- 如果 (当前状态 & 需要的区间) == 0，说明区间没被占用
if bit.band(current_seat_status, mask) == 0 then
    -- 3. 执行扣减 (即更新状态位)
    local new_status = bit.bor(current_seat_status, mask)
    redis.call('set', key, new_status)
    return 1 -- 抢票成功
else
    return 0 -- 没票了
end

六、 总结

搭建 12306 系统的核心不在于数据库怎么存，而在于：

挡：在请求到达后端前，通过 CDN、网关、验证码挡掉绝大部分流量。

缓存：所有查询走内存，Redis 是命脉。

异步：下单不等待数据库，走 MQ 排队，削峰填谷。

原子性：利用 Redis Lua 或数据库乐观锁解决超卖。

这是一场空间换时间（多级缓存）和用户体验换稳定性（排队机制）的战役。