基于SpringBoot的租车系统毕设实战：从需求建模到高可用部署

最近在辅导学弟学妹做毕业设计，发现很多“基于SpringBoot的租车系统”项目，虽然功能列表很长，但仔细一看，架构松散，业务逻辑像面条代码，更别提应对真实场景下的并发问题了。今天，我就结合自己做过的一个相对完整的租车项目，聊聊如何把一个毕业设计做得更“工程化”，从需求建模一路走到可部署的线上服务。

1. 背景痛点：为什么你的毕设只是“玩具”？

很多同学做毕设，容易陷入几个误区：

• 功能堆砌，缺乏主线：车辆CRUD、用户CRUD、订单CRUD……功能列表很全，但各个模块之间是孤立的。用户怎么选车？下单后车辆状态怎么变？订单超时未支付怎么处理？这些核心的业务流没有串联起来。
• 无视并发，数据“裸奔”：这是最普遍的问题。比如“租车”这个动作，本质是减少车辆库存。如果两个用户同时租同一辆车，你的系统会不会出现“一车多租”？大部分毕设项目直接用update vehicle set status = 'rented' where id = xxx，这在并发下一定会出问题。
• 架构混乱，难以扩展：Controller里直接写几百行的业务逻辑，Service层成了“传话筒”，各种if-else嵌套。后期想加个优惠券功能或者积分系统，发现无从下手，牵一发而动全身。

所以，我们的目标不是做一个能跑通的Demo，而是构建一个有清晰业务边界、能处理并发、且易于维护的系统。

2. 技术选型：为什么是SpringBoot + MyBatis-Plus + Redis？

• SpringBoot vs 传统SSM：这不是新旧之争，而是效率之争。SSM（Spring+SpringMVC+MyBatis）需要大量XML配置，整合过程繁琐。SpringBoot的“约定大于配置”和自动装配特性，让我们能快速搭建项目骨架，把精力集中在业务开发上。对于毕设这种时间紧、要求快速出成果的场景，SpringBoot是首选。

• MyBatis-Plus：它是对MyBatis的增强，提供了通用的Mapper和Service，单表CRUD几乎不用写SQL。更重要的是，它内置了分页插件和乐观锁插件，后者对我们实现并发控制至关重要。

• Redis的必要性：很多人觉得Redis就是做缓存，在毕设里可有可无。但在租车场景，它的核心作用是实现高并发下的库存扣减。关系型数据库（如MySQL）的写操作在并发下是瓶颈，而Redis基于内存，命令执行是单线程原子性的，非常适合做秒杀、抢购、租车这类“库存扣减”操作。我们可以用Redis的decr命令或者更复杂的Lua脚本来保证“超租”不会发生。

3. 核心实现：订单与状态机的艺术

3.1 幂等性设计：防止重复下单

网络抖动时，用户可能连续点击“提交订单”，如果后端不做防护，就会创建多个内容相同的订单。幂等性意味着同一操作执行多次，结果与执行一次相同。

实现方案：在提交订单的接口中，要求客户端传递一个全局唯一的“请求号”（比如orderToken，可以用UUID生成）。服务器端用这个orderToken作为Key，在Redis中设置一个短期有效的标记（例如5分钟）。

@PostMapping("/create") public ApiResponse createOrder(@RequestBody OrderCreateDTO dto, HttpServletRequest request) { String orderToken = dto.getOrderToken(); String redisKey = "order:token:" + orderToken; // 使用Redis的setIfAbsent命令，保证原子性 Boolean success = redisTemplate.opsForValue().setIfAbsent(redisKey, "PROCESSING", 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(success)) { // 如果key已存在，说明是重复请求 return ApiResponse.fail("请勿重复提交订单"); } try { // 真正的创建订单业务逻辑 orderService.createOrder(dto); return ApiResponse.success("订单创建成功"); } finally { // 业务处理完成后，可以删除或修改这个token的状态，也可以保留用于后续查询 // redisTemplate.delete(redisKey); } }

3.2 车辆状态机与并发控制

车辆的状态流转是业务核心，必须清晰定义且防止状态混乱。例如：AVAILABLE（可租） ->LOCKED（已锁定，下单未支付） ->RENTED（已出租） ->AVAILABLE（归还后）。

难点在于状态转换的并发安全。比如，车辆从AVAILABLE变为LOCKED时，必须确保同一时刻只有一个请求能成功。

方案一：数据库乐观锁在车辆表vehicle中添加一个version字段（整数类型，默认0）。MyBatis-Plus可以很方便地使用@Version注解。

// Vehicle 实体类 @Data @TableName("vehicle") public class Vehicle { private Long id; private String status; // 状态：AVAILABLE, LOCKED, RENTED... @Version private Integer version; // 乐观锁版本号 // ... 其他字段 } // 在Service中更新状态 public boolean lockVehicle(Long vehicleId) { Vehicle vehicle = vehicleMapper.selectById(vehicleId); if (!"AVAILABLE".equals(vehicle.getStatus())) { return false; // 状态不符合，无法锁定 } vehicle.setStatus("LOCKED"); // updateById时，MyBatis-Plus会自动在SQL中加上 version = #{version} 条件 int rows = vehicleMapper.updateById(vehicle); // 如果rows==0，说明更新失败（版本号不匹配或被其他线程修改） return rows > 0; }

方案二：Redis原子操作（推荐用于极高并发）将车辆库存或状态放在Redis中。例如，为每辆车设置一个Key，值为状态。使用Redis的SET key value NX（仅在键不存在时设置）或WATCH/MULTI/EXEC事务，可以保证操作的原子性。更优雅的方式是使用Lua脚本，它能将多个操作作为一个原子命令执行。

-- Lua脚本：锁定车辆（仅当状态为AVAILABLE时） local key = KEYS[1] -- 车辆状态key，如 `vehicle:status:1001` local currentStatus = redis.call('GET', key) if currentStatus == 'AVAILABLE' then redis.call('SET', key, 'LOCKED') return 1 -- 成功 else return 0 -- 失败 end

在Java中调用：

// 加载Lua脚本（项目启动时一次） private static final DefaultRedisScript<Long> LOCK_SCRIPT = new DefaultRedisScript<>(); static { LOCK_SCRIPT.setScriptSource(new ResourceScriptSource(new ClassPathResource("lua/lockVehicle.lua"))); LOCK_SCRIPT.setResultType(Long.class); } public boolean lockVehicleWithRedis(Long vehicleId) { String key = "vehicle:status:" + vehicleId; Long result = redisTemplate.execute(LOCK_SCRIPT, Collections.singletonList(key)); return result != null && result == 1L; }

4. 性能与安全：让系统更健壮

• JWT鉴权：用户登录后，服务器生成一个JWT Token返回给前端。后续请求都在Header中携带此Token。Spring Security结合jjwt库可以很方便地实现。好处是无状态，适合分布式系统。

• SQL注入防护：坚持使用MyBatis的#{}预编译占位符，绝对不要用字符串拼接SQL（${}要慎用）。MyBatis-Plus的Wrapper查询机制也很好地避免了手写SQL字符串。

• 接口限流：防止恶意刷单或爬虫。可以使用Guava RateLimiter做单机限流，或者用Redis记录IP/用户在一段时间内的访问次数，实现分布式限流。Spring Boot也有@RateLimit注解的第三方库。

5. 生产避坑指南

1. 时间与时区：数据库datetime字段、JavaDate/LocalDateTime、返回给前端的时间戳，这三者的时区必须统一。建议：后端全部使用UTC时间存储和处理，返回给前端时，可以转换为前端所在时区的时间字符串，或者直接返回时间戳由前端自己转换。
2. 事务边界：@Transactional注解不要滥用。事务范围过大（比如包裹整个Service方法）会导致数据库连接持有时间过长，影响性能。应将事务控制在最小的必要范围内，例如只包含核心的写库操作。
3. 测试数据污染：写单元测试或集成测试时，一定要用@Transactional注解并在测试后回滚，或者使用独立的测试数据库。避免测试数据影响开发环境。
4. 配置文件敏感信息：数据库密码、Redis密码、JWT密钥等绝不能硬编码在代码里或提交到Git。要使用application.yml配合环境变量，或者使用Spring Cloud Config、Apollo等配置中心。

6. 部署与扩展思考

项目完成后，可以用Docker进行容器化部署，编写一个docker-compose.yml文件，把MySQL、Redis和你的SpringBoot应用编排在一起，实现一键启动。这绝对是毕设答辩时的亮点。

更进一步思考，现在的系统里，下单成功后，发送短信通知用户、给车主发消息这些操作，都是同步在订单服务里完成的。如果通知服务挂了，会不会影响下单主流程？这时就可以引入消息队列（如RabbitMQ、RocketMQ）来解耦。订单创建成功后，只需向队列发一条消息，由独立的通知服务去消费和处理。这样系统的鲁棒性和扩展性就大大增强了。

做毕设不仅是完成一个功能，更是体验一次小型软件产品的开发全流程。从需求分析、技术选型、核心编码、安全防护到部署上线，每一步都藏着学问。希望这篇笔记能帮你避开一些坑，做出一个让导师眼前一亮的租车系统。