1. 项目概述为什么我们要挑战“仿12306”做Java开发的朋友尤其是工作了三五年想往高级、架构方向发展的总绕不开一个话题高并发。面试八股文背得滚瓜烂熟什么ReentrantLock、线程池、Redis缓存、消息队列说起来头头是道。但真让你从零设计一个能扛住春运级别流量的售票系统心里是不是还有点发虚这就是我们这个系列项目的由来——基于Spring Boot 3.0手把手带你从零搭建一个具备高并发处理能力的仿12306售票系统。12306这个国民级应用早已成为技术圈里“高并发”的代名词。它面临的挑战极其典型瞬时海量查询、库存精准扣减、分布式事务、系统高可用。我们复现它不是为了做一个能上线的产品而是为了把那些散落在各处的知识点——Java并发编程、Spring生态、数据库设计、缓存策略、分布式协调——像串珍珠一样在一个完整的、有业务场景的项目里串联起来让你真正理解它们是如何协同工作的。选择Spring Boot 3.0作为技术栈起点是因为它代表了现代Java开发的最新实践。它内置了对Java 17的支持提供了更完善的GraalVM原生镜像探索路径并且在响应式编程、观测性Micrometer, Observability等方面有了更深的集成。从3.0开始上手能让你接触到更前沿、更工程化的解决方案。这个系列的第一篇我们不急着写代码。磨刀不误砍柴工我会带你系统性地梳理构建这样一个系统所必需的前置知识图谱。这些知识就像建筑的地基地基不稳后面无论用多炫酷的技术系统都可能在高并发压力下崩塌。我会结合我过去在电商大促和票务系统项目中踩过的坑告诉你哪些知识是核心必会的以及它们将如何在我们后续的系统中发挥作用。2. 核心知识图谱构建高并发售票系统的四大支柱要驾驭一个仿12306的系统你不能只盯着“Spring Boot怎么配”或者“MyBatis怎么用”。我们需要建立一个立体的、分层的知识体系。我把它们归纳为四大支柱并发编程基础、数据库与事务、缓存与消息、分布式系统概念。下面我们来逐一拆解并说明它们在售票场景下的具体应用。2.1 并发编程基石不止是synchronized和volatile一提高并发很多人第一反应就是锁。但锁只是手段不是目的。我们的目的是在保证数据正确性的前提下尽可能地提升系统的吞吐量。核心概念与售票场景映射线程与线程池每一个用户购票请求在服务端通常都会由一个线程来处理。直接为每个请求创建新线程new Thread()在高峰期就是灾难。我们必须使用线程池ThreadPoolExecutor来管理这些线程资源控制并发数避免资源耗尽。在Spring Boot中我们会配置Web服务器如Tomcat的线程池以及自定义业务线程池来处理耗时任务如订单处理。共享资源与竞态条件最典型的共享资源就是车票库存。多个线程同时查询并尝试购买同一车次同一座席的最后一张票如果不加控制必然出现“超卖”。这就是竞态条件。锁机制synchronizedJVM内置锁简单易用但在跨JVM的分布式环境下无能为力。它适合在单机、单服务内保护关键区块比如初始化本地缓存。ReentrantLockJDK提供的显式锁比synchronized更灵活支持尝试获取锁tryLock、公平锁等。在复杂的锁逻辑中可能用到。分布式锁这是高并发售票的关键。因为我们的服务肯定是多实例部署的synchronized和ReentrantLock都只能锁住当前JVM进程。要保证集群环境下库存扣减的唯一性必须引入像RedisRedisson客户端或ZooKeeper实现的分布式锁。这是我们后续实现“一人一票”的核心。原子类AtomicInteger,LongAdder等。对于简单的计数操作比如秒杀场景下的库存预热计数器使用原子类比锁的性能更高。但注意它不能解决复合操作的原子性问题比如“查询-判断-扣减”。并发容器ConcurrentHashMap,CopyOnWriteArrayList等。在售票系统中我们可能会用ConcurrentHashMap来缓存一些热点车次的信息如车站映射保证多线程读写的安全与高效。踩坑心得不要滥用synchronized。我曾在一个早期项目里把整个购票方法都synchronized了结果系统吞吐量惨不忍睹完全没发挥出多线程的优势。正确的做法是缩小锁的粒度并优先考虑无锁设计如使用Redis的原子操作或乐观锁。2.2 数据库与事务数据一致性的生命线数据库是系统的“账本”尤其对于交易系统数据的一致性、准确性是底线。核心技术与售票场景映射事务与ACID购票是一个典型的事务操作扣减库存、生成订单、更新用户票夹。必须保证这些操作要么全成功要么全失败原子性。我们会使用Spring的Transactional注解来管理事务。隔离级别与幻读/不可重复读MySQL默认的REPEATABLE READ级别能解决大部分问题但在高并发更新下你需要深刻理解“幻读”对库存统计可能产生的影响。有时为了性能我们会在业务代码层面做补偿而不是一味提高隔离级别。乐观锁与悲观锁悲观锁SELECT ... FOR UPDATE。直接锁住记录其他事务无法修改。简单粗暴但并发性能差容易导致死锁。在12306这种场景下几乎不会用行级悲观锁来扣库存。乐观锁这是我们实现数据库层面防超卖的常用手段。给库存表增加一个version字段或使用update_time。更新时带上条件UPDATE ticket_stock SET stock stock - 1, version version 1 WHERE id ? AND version ? AND stock 0。如果更新影响行数为0说明版本号不对或库存不足购票失败。这种方式并发性能更好。索引设计与SQL优化车票查询条件复杂日期、车次、出发/到达站、座位类型。如何设计联合索引来支撑海量查询避免全表扫描是DBA和开发需要紧密合作的重点。一个错误的索引可能导致数据库在高峰期被拖垮。连接池HikariCP是Spring Boot的默认选择性能优异。必须正确配置maximumPoolSize、connectionTimeout等参数使之与你的应用服务器线程池大小相匹配避免数据库连接成为瓶颈。2.3 缓存与消息系统性能的加速器与解耦器当数据库无法承受直接的压力时缓存和消息队列就登场了。缓存以Redis为例在售票中的应用热点数据缓存车站列表、车次基本信息、城市编码等不常变的数据直接放在Redis里减少数据库查询。库存缓存关键这是缓解数据库压力的核心策略。我们可以在活动开始前将车票库存比如“G101次一等座100张”预加载到Redis中使用hash或string结构存储。用户查询库存时直接读Redis。扣减库存时先使用Redis的原子命令如DECRBY、HINCRBY进行操作。这比直接操作数据库快几个数量级。分布式Session用户登录状态、验证码等信息存于Redis实现多服务实例间的状态共享。分布式锁如前所述使用Redisson实现。消息队列以RabbitMQ/RocketMQ为例的作用异步削峰用户提交购票请求后立即返回“排队中”或“处理中”。真正的创建订单、扣减库存数据库、通知支付等耗时操作放入消息队列由后台消费者异步处理。这样能快速释放Web服务器线程应对更多请求。应用解耦购票成功后需要触发多个下游动作发送短信通知、更新用户积分、记录日志等。通过发出一条消息让不同的消费者订阅处理系统间耦合度大大降低。流量削峰在秒杀开始瞬间将所有请求先写入消息队列然后按照服务端的处理能力慢慢消费避免瞬时流量击垮系统。实操要点使用缓存库存时必须考虑缓存与数据库的数据一致性问题。常用策略是先更新数据库再删除缓存Cache-Aside Pattern。更复杂的场景可能用到延时双删、或通过消息队列同步。在我们的项目中这会是一个重点讨论的设计难点。2.4 分布式系统概念从单机到集群的思维转变当系统从一个“胖”应用拆分成多个服务或者一个服务需要部署多个实例时你就进入了分布式系统的领域。必须了解的概念CAP与BASE理论CAP一致性、可用性、分区容错性告诉你分布式系统无法三者兼得通常需要取舍。12306在春运高峰期可能会为了可用性A而暂时牺牲一部分强一致性C采用最终一致性BASE理论。比如你可能会先看到“排队成功”稍后才能在订单列表里查到。服务注册与发现我们的售票服务、订单服务、支付服务可能都是独立的。它们如何找到彼此这就需要像Nacos或Eureka这样的注册中心。Spring Cloud Alibaba是目前非常流行的选择。配置中心数据库连接、Redis地址、开关配置等不应该硬编码在代码里。使用Nacos Config或Apollo统一管理修改后能动态推送到所有服务实例。链路追踪与监控一个购票请求经过了网关、用户服务、票务服务、订单服务、支付服务。如何追踪它的完整路径和性能瓶颈需要SkyWalking、Zipkin这类工具。Spring Boot 3.0在可观测性上做了很多集成方便我们接入。分布式事务这是最难的部分。扣减库存票务服务和创建订单订单服务如何保证同时成功或失败我们会探讨几种方案基于消息队列的最终一致性、Seata框架的AT/TCC模式等。在真实的高并发场景下柔性事务最终一致性往往是更务实的选择。3. 环境与工具准备工欲善其事必先利其器在开始编码前请确保你的开发环境已经就绪。这里我推荐一套兼顾效率和稳定性的组合。3.1 基础开发环境搭建JDK 17Spring Boot 3.0最低要求JDK 17。我强烈建议直接使用JDK 21 LTS长期支持版它能带来更好的性能和新特性支持如虚拟线程的初步探索。去Oracle官网或Adoptium下载安装。IDEIntelliJ IDEA Ultimate社区版也够用但Ultimate版对Spring Boot、数据库工具、Profiler的支持更完善能极大提升开发效率。这是值得投资的工具。构建工具Maven 3.6 或 Gradle 7.xSpring Boot对两者都支持良好。Maven生态更成熟稳定Gradle构建脚本更灵活。本系列选用Maven因为它的pom.xml配置对大多数Java开发者更直观。版本控制Git毫无疑问。在GitHub或Gitee上创建一个仓库用于管理我们的项目代码。3.2 中间件安装与配置本地开发为了模拟真实环境我们需要在本地或通过Docker启动一系列中间件。MySQL 8.0主数据库。建议使用Docker一键安装docker run --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORDyourpassword -d mysql:8.0。记得用客户端如DataGrip、Navicat连接并创建好数据库sale_ticket_db。Redis 7.x缓存与分布式锁。Docker命令docker run --name redis7 -p 6379:6379 -d redis:7-alpine。可以使用redis-cli或Another Redis Desktop Manager进行管理。RabbitMQ 3.12消息队列。Docker命令docker run -d --hostname my-rabbit --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.12-management。管理界面访问http://localhost:15672默认账号密码guest/guest。Nacos 2.x作为注册中心和配置中心。Docker命令docker run --name nacos -e MODEstandalone -p 8848:8848 -d nacos/nacos-server:v2.2.3。控制台地址http://localhost:8848/nacos。避坑指南本地同时运行这么多容器对内存是个考验。建议机器至少配备16GB内存。如果资源紧张可以只启动当前开发阶段必需的中间件或者考虑使用云厂商提供的免费试用服务。3.3 Spring Boot 3.0项目初始化打开IDEA使用 Spring Initializr 创建项目Project: MavenLanguage: JavaSpring Boot: 选择最新的 3.x.x 版本确保是3.0以上Project Metadata:Group:com.yournameArtifact:ticket-systemPackaging: JarJava: 17 或 21Dependencies: 我们初期先添加最核心的Spring Web(构建Web应用)Spring Data JPA或MyBatis Framework(数据库ORM本系列选用MyBatis-Plus这里可以先选MyBatis后续手动改)Lombok(简化Java Bean代码)MySQL Driver(数据库连接)Redis(Spring Data Redis)RabbitMQ(Spring AMQP)点击生成一个标准的Spring Boot 3.0项目骨架就创建好了。检查pom.xml确保父版本是3.x.x。4. 项目核心模块与数据模型初探在动手写代码前我们先对系统要做什么数据怎么存有一个宏观的设计。这能避免后期频繁、痛苦的重构。4.1 系统核心业务流程拆解一个简化的购票核心流程如下用户查询输入日期、出发站、到达站系统返回符合条件的车次列表及余票信息。选择车次席别用户选择具体车次、座位类型一等座、二等座系统再次查询并展示实时余票。提交订单用户确认购票信息系统进行库存预扣减防止票被他人抢走生成一个待支付的订单。支付用户在规定时间内如15分钟完成支付。出票支付成功后系统执行最终库存扣减更新订单状态为“已出票”并通知用户。订单超时释放如果用户未支付系统在超时后自动取消订单并释放预扣的库存。你会发现库存扣减有两次一次是提交订单时的“预扣”锁定库存一次是支付成功后的“实扣”。这是保证“有票可卖”和“防止占票不付”的关键设计。4.2 核心数据表设计草图基于以上流程我们至少需要设计以下几张核心表1. 车次信息表 (train_info)存储车次的基础信息相对静态。CREATE TABLE train_info ( id bigint PRIMARY KEY AUTO_INCREMENT, train_number varchar(20) NOT NULL COMMENT 车次号如G101, train_type varchar(10) COMMENT 车型高铁、动车、普快等, start_station_code varchar(10) COMMENT 始发站编码, end_station_code varchar(10) COMMENT 终点站编码, start_time time COMMENT 始发时间, end_time time COMMENT 到达终点时间, total_duration int COMMENT 总运行时长分钟, status tinyint DEFAULT 1 COMMENT 状态1-可售0-停售 ) COMMENT 车次基础信息表;2. 车次站点时刻表 (train_station)这是12306查询的核心记录了车次经过的每一个车站的信息。CREATE TABLE train_station ( id bigint PRIMARY KEY AUTO_INCREMENT, train_number varchar(20) NOT NULL COMMENT 车次号, station_index int NOT NULL COMMENT 车站序号从1开始, station_code varchar(10) NOT NULL COMMENT 车站编码, station_name varchar(50) NOT NULL COMMENT 车站名, arrive_time time COMMENT 到达时间, departure_time time COMMENT 出发时间, stopover_time int COMMENT 停留时长分钟, distance_from_start int COMMENT 距始发站里程公里, KEY idx_train_number (train_number), KEY idx_station_code (station_code) ) COMMENT 车次站点时刻表;设计要点查询“北京南到上海虹桥的G101次”时实际上是在这张表中找到train_numberG101且station_code分别是‘北京南’和‘上海虹桥’的两条记录并确保‘北京南’的station_index小于‘上海虹桥’的。3. 座位库存表 (seat_inventory)这是最核心、并发压力最大的表。它按车次、日期、座位类型、区间来记录库存。CREATE TABLE seat_inventory ( id bigint PRIMARY KEY AUTO_INCREMENT, train_number varchar(20) NOT NULL COMMENT 车次号, departure_date date NOT NULL COMMENT 出发日期, seat_type varchar(10) NOT NULL COMMENT 座位类型一等座、二等座等, start_station_code varchar(10) NOT NULL COMMENT 区间起始站编码, end_station_code varchar(10) NOT NULL COMMENT 区间终点站编码, total_inventory int NOT NULL DEFAULT 0 COMMENT 总库存物理座位数, available_inventory int NOT NULL DEFAULT 0 COMMENT 可售库存, locked_inventory int NOT NULL DEFAULT 0 COMMENT 已锁定库存已下单未支付, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, UNIQUE KEY uk_train_date_seat_route (train_number, departure_date, seat_type, start_station_code, end_station_code), KEY idx_date_train (departure_date, train_number) ) COMMENT 座位区间库存表;核心难点解析为什么库存要按“区间”存储因为一张票从北京到上海可以被拆分成“北京-南京”和“南京-上海”两个区间售卖给不同的人席位复用。我们的库存模型必须支持这种复杂的区间计算。available_inventory total_inventory - locked_inventory - 已售出票数。扣减时会影响所有与之重叠的区间库存。4. 订单表 (ticket_order)记录用户的购票订单。CREATE TABLE ticket_order ( id varchar(32) PRIMARY KEY COMMENT 订单号业务生成, user_id bigint NOT NULL COMMENT 用户ID, train_number varchar(20) NOT NULL, departure_date date NOT NULL, start_station_code varchar(10) NOT NULL, end_station_code varchar(10) NOT NULL, seat_type varchar(10) NOT NULL, amount decimal(10,2) NOT NULL COMMENT 订单金额, status tinyint NOT NULL COMMENT 状态0-待支付1-已支付2-已出票3-已取消4-已退款, create_time datetime NOT NULL, pay_time datetime, expire_time datetime COMMENT 支付过期时间, KEY idx_user_id (user_id), KEY idx_create_time (create_time) ) COMMENT 订单表;这只是最核心的几张表实际系统还会有用户表、乘客表、支付流水表等。有了这个数据模型基础我们后续的代码开发才能有的放矢。5. 高并发设计核心思想与常见误区在进入具体编码前我们必须统一几个核心设计思想这些思想将贯穿项目始终。5.1 核心思想分层过滤、逐级衰减像12306这样的系统请求压力不是均匀的而是呈现明显的“漏斗模型”。我们的设计目标就是在这个漏斗的每一层都过滤掉无效或可缓存的请求让最终落到数据库的写请求尽可能少。前端/客户端层按钮防重复点击、验证码防止脚本、请求频率限制。网关/负载均衡层限流如令牌桶、漏桶算法、黑名单。业务应用层读多写少大量查询请求查余票走缓存Redis。采用“缓存数据库”结合缓存命中率是关键优化指标。写请求购票请求先进入消息队列进行削峰填谷后端消费者按能力处理。库存扣减采用Redis预扣减 数据库最终扣减相结合利用Redis的高性能扛住瞬时并发。数据库层最后的防线。通过分库分表按车次或日期、读写分离、优化索引和SQL来提升处理能力。5.2 必须避开的常见误区误区一所有请求都平等对待。不对请求进行分级。查询余票的请求和提交订单的请求对系统资源的消耗和重要性天差地别。必须设计不同的限流和降级策略。误区二迷信数据库事务。在超高并发下长事务、大事务是数据库的杀手。购票流程中应尽量将非核心操作如写日志、发通知异步化缩短数据库事务持有时间。误区三缓存只用不更新。缓存了库存但更新策略混乱导致缓存数据与数据库不一致出现“超卖”或“有票不能卖”。必须设计清晰的缓存更新和失效策略。误区四过早过度设计。在项目初期就引入所有可能的分布式组件追求“大而全”的架构反而让系统变得复杂难维护。应该遵循“演进式架构”随着业务压力和团队能力的增长逐步引入必要的技术。5.3 性能压测如何证明你的系统真的“高并发”设计做完了代码写好了怎么知道它能扛住多少压力这就需要压测。我们后续会使用JMeter来模拟高并发场景。关键的压测场景设计场景一余票查询压测模拟大量用户同时查询热门车次的余票。关注QPS每秒查询率、响应时间、缓存命中率。场景二下单压测模拟秒杀场景大量用户同时抢购同一车次的少量车票。关注下单成功率、库存准确性、订单创建耗时、消息队列堆积情况。监控指标在压测过程中必须监控应用服务器CPU、内存、线程池状态、GC情况。数据库连接数、QPS、慢查询、锁等待。Redis内存使用、连接数、命令耗时。消息队列堆积消息数、消费速率。压测不是一次性的工作而是伴随系统迭代的常态化活动。只有通过压测你才能发现系统的真实瓶颈在哪里是数据库连接池不够了还是某段代码有锁竞争或者是缓存策略出了问题。6. 前置知识自检清单与学习建议在进入下一篇《项目搭建与基础架构》之前你可以对照下面这个清单检查一下自己的准备情况。如果有不熟悉的知识点建议花点时间补上这会让你后续的学习事半功倍。知识领域自检清单领域关键知识点掌握程度1-5分学习建议/资料Java核心多线程Thread, Runnable、线程池ThreadPoolExecutor、锁synchronized, ReentrantLock、原子类、并发容器《Java并发编程实战》、JDK官方文档Spring Boot核心注解SpringBootApplication, RestController等、自动配置、YAML配置、Starter机制Spring Boot官方文档、常用StarterWeb, Data, Redis等数据库MySQL索引原理B树、事务隔离级别、SQL优化EXPLAIN、乐观锁实现《高性能MySQL》、数据库慢查询日志分析Redis五种基本数据结构、持久化机制、事务、Lua脚本、Redisson分布式锁Redis命令参考、Redisson官方Wiki消息队列RabbitMQ/RocketMQ核心概念Producer, Consumer, Exchange, Queue、消息确认机制、死信队列对应中间件的官方Quick Start分布式基础CAP理论、服务注册发现概念、配置中心概念、RESTful API设计了解基本概念即可后续边做边学工具Git基本操作、Maven依赖管理、Docker基础命令、IDEA Debug技巧日常多用熟能生巧如果你大部分能打到3分以上那么恭喜你可以愉快地开始我们的项目之旅了。如果有些地方只有1-2分也不用担心这个系列会结合具体场景带你重新理解和运用这些知识。记住最好的学习方式就是在解决真实问题的过程中学习。下一篇我们将正式启动项目搭建Spring Boot 3.0的多模块工程集成MyBatis-Plus、Redis、RabbitMQ并构建出第一个“Hello World”式的车次查询接口。我们会从最简单的开始一步步增加复杂度最终逼近那个能扛住压力的系统。