LYC邮箱
← 返回项目经历02 / 02

交易内核 / 后端开发 · 2026.03 — 2026.06

12306 高并发售票核心网关

作为交易事实来源，把高并发票务流程里的库存、订单与恢复机制放进一条明确的状态链。

01 / 系统边界

责任先于能力。

角色
Java 交易核心，负责车次查询、订票、支付、退款、库存扣减与订单状态事实。
问题
高并发请求会同时触碰缓存、库存、订单和消息系统；任何局部成功都可能造成超卖、重复操作或状态不一致。

02 / 系统与测试视图

从查询热路径，到订单落位与延迟对账。

这不是产品截图，而是依据项目链路与本地压测报告整理的责任流：读流量、库存事实、订单状态和异步恢复各自保留边界。

  1. 01 / 请求

    查询或订票请求

    入口校验请求并把读路径与会产生副作用的交易路径分开。

  2. 02 / 缓存

    Caffeine + Redis

    查询热路径优先命中多级缓存；预热报告中的请求由本地 Caffeine 缓存承载。

  3. 03 / 库存

    锁与 Lua 预扣

    Redisson 与 Redis Lua 约束热点竞争，并让库存预扣保持原子边界。

  4. 04 / 订单

    MySQL 状态事实

    订单状态机记录待支付、支付、取消与退款等生命周期变化。

  5. 05 / 消息

    RocketMQ 衔接

    事务与延迟消息承接削峰、超时关闭和跨阶段状态推进。

  6. 06 / 恢复

    补偿与延迟对账

    短暂异步延迟后复核库存与订单，异常继续进入回补和恢复路径。
6047.94REQ/S · 查询路径
本地开发环境、Docker JMeter 5.5 与 Sentinel 性能配置；50 用户，30 秒升压、60 秒采样；缓存预热后共 361,782 次请求，0% 错误，P95 17 ms。
510.94REQ/S · 订票子事务
本地 200 用户、20 秒升压、20 秒采样、四个压测车次；10,133 个订票子事务样本，0% 错误，P95 318 ms。
0对账不一致数
在文档记录的数据集内，短暂异步延迟后的对账收敛为 allConsistent=true、mismatchCount=0。

方法边界以上结果来自本地开发环境、特定性能配置与测试数据集，不代表生产容量；吞吐、延迟与对账结论只适用于所列方法和样本范围。

03 / 工程方法

把关键机制放进可检查的路径。

  1. 01

    缓存与库存

    让读流量与库存事实各归其位

    使用 Caffeine 与 Redis 组织多级缓存，以 Redisson 锁和 Redis Lua 完成库存原子扣减，明确缓存命中与交易写入的职责边界。
  2. 02

    订单状态

    用状态机承接完整交易生命周期

    把下单、支付、超时关闭与退款组织为可追踪的订单状态，并通过 RocketMQ 异步削峰与事务消息衔接跨阶段变化。
  3. 03

    故障恢复

    为失败准备补偿与对账路径

    围绕退款补偿、库存回补和状态对账设计恢复机制，并保留 JUnit 覆盖与 JMeter 压测资产作为工程验证入口。

04 / 证据与结果

不靠虚构指标，呈现可验证的工程事实。

  • Caffeine + Redis 多级缓存
  • Redisson 锁与 Redis Lua 原子库存扣减
  • RocketMQ 异步削峰与事务消息
  • 订单状态机、超时关闭与退款补偿
  • JUnit 测试与 JMeter 压测资产

建立从请求进入到库存、订单和消息落位的可追踪交易路径，并为异常状态保留补偿与对账入口。

查看共享仓库

05 / 工程证据

以下图片来自当前本地仓库归档，分别记录票务界面和两组有明确口径的本地负载测试。点击任一图片可查看完整尺寸。

  1. 01运行界面

    车票工作台 · 桌面端

    桌面端车票工作台把查询条件、车次、余票与预订入口放在同一操作流中，用于展示票务系统的界面组织。

    来源 / 本地 Ticket Workbench 运行截图

    证据边界截图展示仓库内的测试界面与合成数据，不代表生产流量、商业采用或真实 12306 服务。

  2. 02运行界面

    车票工作台 · 移动端

    同一票务工作台在窄屏下改为单列信息流；原始长截图完整保留查询、概览与车次列表，不做裁切。

    来源 / 本地 Ticket Workbench 移动端截图

    证据边界该图验证界面在测试数据下的移动端排布，不据此推断生产兼容范围或真实用户使用情况。

  3. 03负载测试

    800 并发查询压测

    独立归档的 800 并发用户查询场景记录 5409.54 QPS、P95 357 ms 与 0% HTTP 错误。它与前文 6047.94 REQ/S 属于不同测试配置，不合并比较。

    来源 / JMeter 查询负载归档 · 2026-05-19

    证据边界结果仅对应图中 query-800u-perf 本地场景、241,785 个样本与当时配置，不代表生产容量。

  4. 04负载测试

    订票前门受理负载

    200 用户场景下记录 510.94 requests/s 的订票前门受理吞吐，并展示 Redis Lua 预扣、RocketMQ、MySQL 订单与延迟对账链路。

    来源 / JMeter 订票负载与一致性归档 · 2026-05-19

    证据边界510.94 requests/s 是登录后的预扣与消息衔接受理口径，不是支付完成后的端到端订单 TPS。