3天搞定广州市公路客运网上售票系统：告别报错，性能优化实战
盯着屏幕上那一片刺眼的红色 Stack Trace，你大概率已经想砸键盘了。NullPointerException 或者 ConnectionTimeout 满屏飞，根本不知道从哪一行代码开始查起。这种“报错一堆看不懂”的绝望感，是每个后端开发在接手或重构老系统时的必经之路。
今天我们要聊的，是一个极具代表性的实战案例：广州市公路客运网上售票系统。别被这个名字吓到，它本质上就是一个高并发的分布式票务系统。我见过太多开发者在这个系统里栽跟头，不是代码逻辑错了，而是性能优化没做对，导致高峰期直接崩盘。
这篇文章不整虚的，我们直接从工程化角度，把这个系统从零搭起来。你会看到真实的目录结构、核心代码实现，以及那些能让系统扛住并发洪流的性能优化技巧。哪怕你是刚入行的新手，跟着敲完这套代码，对高并发处理的理解也能上一个台阶。
项目目标与架构选型
在动手写代码之前，先明确我们要解决什么问题。一个标准的公路客运售票系统，核心业务流程很简单：用户查询班次 -> 选择座位 -> 下单支付 -> 出票。但魔鬼藏在细节里：
- 高并发查询：春运期间，成千上万用户同时查询同一线路，数据库扛不住。
- 座位超卖：两个用户同时抢最后一个座位，必须保证数据一致性。
- 库存扣减：票务库存是核心资源，必须原子操作。
为了在 3 天内跑通核心流程并具备可扩展性，我们选择 Spring Boot + MyBatis-Plus + Redis + MySQL 技术栈。这是国内企业最主流的组合，招聘需求量大，且资料丰富。
为什么选 Redis？ 因为 MySQL 在处理高频读请求时，性能瓶颈非常明显。我们将班次信息、剩余票数等热点数据缓存到 Redis 中，数据库只负责最终持久化和复杂查询。
核心目标：
- 实现座位的并发安全锁定。
- 查询接口响应时间控制在 50ms 以内。
- 支持水平扩展，无状态服务设计。
目录结构与工程化规范
很多初学者喜欢把代码全堆在 Service 层，导致后期维护简直是灾难。我们采用标准的分层架构，确保代码职责单一。
ticket-system/
├── src/main/java/com/gz/ticket/
│ ├── config/ # 配置类（Redis, Web, Exception）
│ ├── controller/ # 接口层（接收请求，参数校验）
│ ├── service/ # 业务层（核心逻辑，事务控制）
│ ├── mapper/ # 数据层（MyBatis 接口）
│ ├── entity/ # 数据库实体类
│ ├── dto/ # 数据传输对象（前端交互）
│ ├── common/ # 通用工具（Result, 常量, 异常）
│ └── TicketApplication.java
├── src/main/resources/
│ ├── application.yml # 配置文件
│ ├── mapper/ # MyBatis XML 映射文件
│ └── static/ # 静态资源（可选）
└── pom.xml
关键文件说明：
Result.java：统一响应格式。前端讨厌不一致的返回结构，我们定义{code, msg, data}三元组，所有接口必须返回这个对象。GlobalExceptionHandler.java：全局异常捕获。这是解决“报错看不懂”的第一道防线。所有的Exception都会在这里被拦截，转换成友好的 JSON 返回给前端，而不是直接抛出 500 页面。
在 pom.xml 中，除了引入 Spring Boot Starter Web 和 MyBatis Plus，别忘了引入 lombok 和 hutool。Lombok 能减少大量的 Getter/Setter 样板代码，Hutool 提供了一些便捷的字符串和集合工具，能提升开发效率。
核心代码实现与逐行解析
接下来进入硬核部分。我们实现最核心的功能：查询班次列表 和 锁定座位。
1. 统一异常处理：让报错不再神秘
很多开发者遇到报错，第一反应是看控制台，但生产环境控制台往往只有一行 Internal Server Error。我们需要一个全局异常处理器。
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import com.gz.ticket.common.Result;
import lombok.extern.slf4j.Slf4j;@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {/*** 捕获所有未处理的异常*/@ExceptionHandler(Exception.class)public Result<?> handleException(Exception e) {// 关键：记录完整堆栈到日志文件，而不是直接返回给前端log.error("系统发生未知异常", e);// 返回给前端的错误信息要模糊，避免暴露系统细节return Result.error(500, "系统繁忙，请稍后再试");}/*** 捕获业务自定义异常*/@ExceptionHandler(BusinessException.class)public Result<?> handleBusinessException(BusinessException e) {// 业务异常，比如“座位已售罄”，直接返回具体错误码return Result.error(e.getCode(), e.getMessage());}
}
逐行讲解：
@RestControllerAdvice：这是 Spring 提供的注解，类似于@ControllerAdvice，但返回的是 JSON 而非视图。它会将所有 Controller 层抛出的异常集中处理。log.error("...", e)：注意这里传入了异常对象e。Slf4j 会自动打印完整的 StackTrace 到日志文件。这样即使前端只看到“系统繁忙”，运维人员也能在日志里看到确切的报错行号。- 避坑指南：千万不要在异常处理器里
e.printStackTrace()，这只会输出到标准输出流，生产环境根本看不到。必须使用日志框架。
2. 班次查询：Redis 缓存优化
查询接口是流量最大的入口。如果每次都查 MySQL，数据库连接池很快会被打满。
@Service
public class TicketService {@Autowiredprivate TicketMapper ticketMapper;@Autowiredprivate RedisTemplate<String, Object> redisTemplate;private static final String CACHE_KEY_PREFIX = "ticket:line:";/*** 查询某条线路的班次列表*/public List<TicketDto> queryLine(String lineId) {String cacheKey = CACHE_KEY_PREFIX + lineId;// 1. 尝试从 Redis 获取List<TicketDto> cacheData = (List<TicketDto>) redisTemplate.opsForValue().get(cacheKey);if (cacheData != null) {return cacheData;}// 2. 缓存未命中，查询数据库List<Ticket> tickets = ticketMapper.selectByLineId(lineId);// 3. 转换为 DTO 并放入 RedisList<TicketDto> dtoList = tickets.stream().map(this::convertToDto).collect(Collectors.toList());// 设置过期时间 5 分钟，防止数据不一致redisTemplate.opsForValue().set(cacheKey, dtoList, 5, TimeUnit.MINUTES);return dtoList;}
}
性能优化要点：
- 缓存穿透防护：如果查询的数据在 DB 中也不存在，
cacheData为 null，我们会去查 DB。如果 DB 也没数据，我们应该缓存一个空对象或特殊标记，防止恶意请求频繁击穿缓存。 - TTL 设置：5 分钟是一个经验值。太短了缓存命中率低，太长了用户看到的座位状态可能滞后。根据业务场景调整。
3. 座位锁定：解决并发超卖
这是最容易出 Bug 的地方。如果两个用户同时点击“下单”，普通的 UPDATE 语句会导致超卖。
错误示范（绝对不要用）：
// 1. 查库存
int count = ticketMapper.selectCount(stockId);
// 2. 判断库存
if (count > 0) {// 3. 扣减库存ticketMapper.updateStock(stockId, -1);
}
在并发下，步骤 1 和 3 之间有时间差，两个线程可能同时读到 count > 0，导致多卖一张票。
正确方案：数据库乐观锁 + Redis 预扣减
为了简化演示，我们采用数据库层面的原子操作。
/*** 锁定座位* @param ticketId 班次ID* @param seatNo 座位号*/
public void lockSeat(Long ticketId, String seatNo) {// 1. 构造更新条件// 利用数据库的 UPDATE ... WHERE status = 0 (空闲)// 如果 status 已经是 1 (已锁定)，则更新行数为 0int rows = ticketMapper.lockSeat(ticketId, seatNo);// 2. 判断更新结果if (rows == 0) {throw new BusinessException(400, "座位已被占用或不存在");}// 3. 发送延迟队列消息，如果 15 分钟未支付，释放座位// 这里省略 RabbitMQ/RocketMQ 的具体实现，仅示意逻辑sendReleaseMessage(ticketId, seatNo, 15);
}
Mapper XML 中的 SQL：
<update id="lockSeat">UPDATE t_ticket_seat SET status = 1, lock_time = NOW(),lock_user_id = #{userId}WHERE ticket_id = #{ticketId} AND seat_no = #{seatNo} AND status = 0
</update>
原理解析：
- 原子性：
UPDATE语句在数据库层面是原子操作。WHERE status = 0是关键。如果第一个线程已经把 status 改成了 1，第二个线程执行同样的 SQL，影响行数（rows）就是 0。 - 无锁并发：这种方案利用了 MySQL 的行锁机制（InnoDB 引擎默认支持），不需要我们在代码里加
synchronized或ReentrantLock。对于高并发场景，数据库的行锁比应用层的 JVM 锁更可靠，因为它不依赖单机。
运行与测试：如何验证性能
代码写完只是第一步，必须通过测试来验证性能优化是否生效。
1. 本地运行
确保 MySQL 和 Redis 服务已启动。修改 application.yml 中的连接配置：
spring:datasource:url: jdbc:mysql://localhost:3306/gz_ticket?useUnicode=true&characterEncoding=utf8username: rootpassword: 123456redis:host: localhostport: 6379
启动项目，访问 /actuator/health 确认服务正常。
2. 压力测试
使用 JMeter 或 Locust 模拟并发请求。
测试场景：
- 并发用户数：1000 个用户。
- 操作：同时查询同一热门线路（如广州->深圳），并尝试购买相同的 10 个座位。
- 预期结果：
- 查询接口 QPS（每秒查询率）应高于 5000。
- 座位购买成功率：10 个座位，最终只有 10 个订单成功，其余 990 个请求应返回“座位已被占用”。
- 绝对不能出现：11 个订单成功（超卖）。
常见测试报错：
如果在测试中出现 Connection Pool Exhausted（连接池耗尽），说明数据库连接数不够。调整 HikariCP 配置：
spring:datasource:hikari:maximum-pool-size: 50 # 根据 CPU 核心数调整，通常为 2 * CPU核数 + 磁盘数
优化扩展与避坑指南
系统跑通后，还有几个关键点决定它能走多远。
1. 缓存一致性
Redis 和 MySQL 数据不一致是常态。
- 策略：采用“Cache Aside Pattern”（旁路缓存）。更新数据库后，删除缓存，而不是更新缓存。
- 原因：更新缓存可能失败，且并发更新时容易乱序。删除缓存后，下次请求会重新加载最新数据。
2. 数据库索引优化
在 t_ticket_seat 表上，必须建立联合索引：
CREATE INDEX idx_ticket_seat_status ON t_ticket_seat(ticket_id, seat_no, status);
这个索引覆盖了查询和更新操作，避免了全表扫描。在高并发下，索引缺失是性能杀手。
3. 日志规范化
不要到处打 System.out.println。统一使用 @Slf4j。
- INFO 级别：记录关键业务流程（如下单成功、支付成功）。
- DEBUG 级别：记录调试信息（如 SQL 执行时间），生产环境关闭。
- ERROR 级别：记录异常，必须包含堆栈信息。
4. 参考开源项目
如果你想看更复杂的分布式锁实现（如 Redisson），可以参考 GitHub 上的开源仓库 Redisson。它在 distributed_lock 模块中实现了 Redlock 算法，比简单的 SETNX 更安全可靠。阅读源码能帮你理解底层原理。
小结
从报错一堆看不懂，到能够从容应对高并发场景，关键在于工程化思维和对细节的掌控。
- 全局异常处理让你不再迷失在 StackTrace 里。
- Redis 缓存让查询接口轻快如风。
- 数据库原子操作保证了数据的一致性，杜绝超卖。
- 压力测试是检验优化效果的唯一标准。
搭建一个广州市公路客运网上售票系统，不仅是写代码，更是学习如何设计一个健壮、可扩展的后端架构。这些技术点（缓存、锁、索引、日志）在任何电商、票务、金融系统中都是通用的。
你在项目里踩过这个坑吗？比如缓存穿透导致数据库宕机，或者并发下数据不一致？评论区聊聊，我们一起拆解解决方案。
