基于Java的民宿管理系统：从订单防超卖到并发控制的实战解析-开发者社区

简介：这份基于Java语言的民宿管理系统设计源码，面向有一定Java基础的开发者、毕业设计学生或中小型民宿业务管理者，用于理解民宿预订、房间管理、用户权限等核心模块的开发思路。压缩包共225个文件，大小33.57MB，其中包含42个Java源文件、93个XML配置文件、40个class文件，以及JAR包、YAML配置、JPG图片等资源，覆盖后端逻辑、部署配置、界面素材和依赖管理。已有385人学习浏览。通过源码可学习Maven项目结构、Spring相关配置、前后端资源组织方式，以及Git忽略规则、Maven Wrapper等工程化实践；内容预览中可见订单、房间、用户等典型业务类，便于直接阅读和二次开发。适合希望快速上手民宿管理系统完整代码、并借助实际项目提升Java企业级开发能力的读者。

1. 民宿管理系统的技术难点从来不在 CRUD，而在超卖与并发

如果把「基于 Java 的民宿管理系统」当成一个增删改查练习，你会错过它真正有价值的部分。民宿和酒店最大的区别在于房源非标、库存分散、预订窗口不固定——同一天可能有 10 个渠道在卖同一间房，而系统要保证只有一个订单能成交。这是典型的“小规模高并发”场景：并发量不大，但对数据一致性要求极高。

一套合格的民宿管理系统源码，核心价值不是界面多漂亮，而是订单状态机是否严谨、库存扣减是否原子、支付回调是否幂等。本文以 Java 技术栈为主线，从数据模型、核心代码、部署参数到压测验证，完整拆解一套可落地的工程方案。你不需要真实的一家民宿来理解这套系统——你需要的是把它当成一个小而完整的电商系统来做，这才是它作为「设计源码」值得细读的地方。

适合的读者有两类：一是准备用 Java 做真实项目的初中级工程师，想看看表结构怎么设计、订单防超卖怎么写；二是准备拿它做面试项目的同学，需要知道在简历上写「Redis 缓存 + 分布式锁 + 消息队列」时，代码里到底应该长什么样。

2. 从需求到表结构：先定数据模型，再写第一行业务代码

2.1 民宿业务的核心实体与关系建模

民宿管理系统的业务面比想象中宽：前台要管房态、预订、入住退房；后台要管房源、价格计划、渠道、财务对账。设计表结构之前，先把领域模型捋清楚，避免后期在 Service 层里做表关联的妥协。

核心实体可以拆成五个维度：房源（House）、房型（RoomType）、库存计划（InventoryPlan）、订单（Order）、价格计划（PricePlan）。这里最容易犯的建模错误是让「房源」和「库存」混在一张表里——民宿经常出现“一套房源拆成两间房卖”或“同一房型在不同渠道价格不同”的逻辑，所以房源是房源，库存是库存，价格是价格，三者必须解耦。

一个经过验证的简化 ER 关系如下：

House（房源表）：民宿的基础信息，包含名称、地址、房东 ID、状态
RoomType（房型表）：挂在房源下，如“大床房”“亲子房”
InventoryPlan（库存计划表）：按「房型 + 日期」记录可售数量，这是防超卖的核心表
PricePlan（价格计划表）：按「房型 + 日期范围 + 渠道」记录价格
BookingOrder（订单表）：客户预订记录，包含订单状态字段

2.2 MySQL 建表语句与字段设计的关键细节

以下是订单表和库存计划表的简化 DDL，重点不是字段多全，而是索引和唯一约束的设计能直接支撑后面的并发控制：

CREATE TABLE `inventory_plan` ( `id` bigint NOT NULL AUTO_INCREMENT, `room_type_id` bigint NOT NULL COMMENT '房型ID', `stay_date` date NOT NULL COMMENT '入住日期', `total_count` int NOT NULL DEFAULT 0 COMMENT '总库存', `booked_count` int NOT NULL DEFAULT 0 COMMENT '已预订数量', `version` int NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_room_date` (`room_type_id`, `stay_date`) ) ENGINE=InnoDB COMMENT='民宿库存计划表'; CREATE TABLE `booking_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `room_type_id` bigint NOT NULL, `check_in_date` date NOT NULL, `check_out_date` date NOT NULL, `guest_name` varchar(50) NOT NULL, `guest_phone` varchar(20) NOT NULL, `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额', `order_status` tinyint NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已入住 3已完成 4已取消', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB COMMENT='民宿订单表';

这段 DDL 里有两个值得注意的设计决策。第一，inventory_plan上建了(room_type_id, stay_date)的唯一索引，这保证了同一个房型同一天只有一条库存记录，后续做行锁更新时有明确的目标行。第二，booking_order的订单号用唯一索引约束，这是幂等设计的基础——同一订单号重复插入会被数据库拒绝。

version字段是留给乐观锁用的，先留着，后文会在代码中说明它的触发时机。很多初学者会在库存表里直接用stock_count字段，更新时set stock_count = stock_count - 1，这在低并发下没问题，但一旦两个请求同时读到同一个库存值，就会双双更新成功，造成超卖。提前加version字段就是为了规避这个风险。

2.3 为什么选择 MyBatis-Plus 而不是纯 MyBatis 或 JPA

在 Java 后端选型上，常见的方案有三条路：原生 MyBatis、MyBatis-Plus、Spring Data JPA。对于民宿管理系统这种“业务逻辑中等复杂、团队换手率高”的项目，我一般会选MyBatis-Plus，理由有三个：

单表 CRUD 零 SQL：房源管理、房型管理这类基础功能，用BaseMapper提供的方法即可，省掉大量重复的 XML 文件
分页插件成熟：订单列表、房源列表是典型的分页场景，MyBatis-Plus 的分页插件一行配置就能用
团队维护成本低：相比 JPA 的隐式查询规则，MyBatis-Plus 的LambdaQueryWrapper可读性更好，新成员上手快

但注意，核心的库存扣减操作不能用 MyBatis-Plus 的updateById去做，因为那个 API 是按主键更新整行，没法在更新条件里加限制。这一块必须走自定义 SQL，后文会单独演示。这也呼应了热词检索里常见的「mybatis源码」、Java 面试题中的「MyBatis 底层原理」——不是让你背源码，而是要知道什么时候该绕过框架的便捷方法，回到 SQL 本身。

2.4 Spring Boot 工程结构与分层规范

项目使用标准的 Spring Boot 分层结构，分包方式如下：

com.bnb ├── controller # HTTP 入口层 ├── service # 业务逻辑层 │ └── impl ├── mapper # MyBatis-Plus Mapper 接口 ├── entity # 数据库实体 ├── dto # 前端交互数据对象 ├── common # 统一返回体、异常处理、常量 ├── config # Redis、MyBatis-Plus、线程池配置 └── task # 定时任务（如取消超时未支付订单）

分包的关键在于依赖方向：controller 依赖 service，service 依赖 mapper，entity 只做数据载体，不持有业务逻辑。这样分层的好处是，当你后续要引入 Redis 缓存或 MQ 时，改动只发生在 service 内部，接口签名和 controller 层都不变。

工程层面，建议 Maven 多模块拆分，把common和dal单独抽出来。民宿管理系统如果只有一个单体模块，后期做多端接入（小程序、管理后台、CRM）时会出现大量重复代码。按bnb-common、bnb-dal、bnb-service、bnb-web四个模块拆，各端只依赖bnb-service层暴露的 API，这才是「设计源码」该有的工程姿态。

3. 核心业务代码：把订单防超卖、库存扣减和缓存一致性写进 Service

3.1 下单流程的状态机设计与代码骨架

民宿订单的状态流转比普通商品订单多两个节点：待入住和已完成。完整的合法流转路径如下：

待支付 → 已取消（用户主动取消或超时未支付）
待支付 → 已支付（支付回调成功）
已支付 → 已入住（到店办理入住）
已入住 → 已完成（退房离店）

这个状态机要写进代码，不能靠前端按钮控制。一个简单的实现是在 Service 里创建一个状态变更方法，每次更新前先校验当前状态是否允许目标状态：

public boolean changeOrderStatus(Long orderId, Integer targetStatus) { BookingOrder order = orderMapper.selectById(orderId); if (order == null) { throw new BizException("订单不存在"); } int current = order.getOrderStatus(); if (!canTransit(current, targetStatus)) { throw new BizException("订单状态不允许从 " + current + " 变更为 " + targetStatus); } LambdaUpdateWrapper<BookingOrder> wrapper = new LambdaUpdateWrapper<>(); wrapper.eq(BookingOrder::getId, orderId) .eq(BookingOrder::getOrderStatus, current); int rows = orderMapper.update(null, wrapper .set(BookingOrder::getOrderStatus, targetStatus)); return rows > 0; } private boolean canTransit(int from, int to) { int[][] allowed = { {0, 1}, {0, 4}, {1, 2}, {1, 4}, {2, 3} }; for (int[] pair : allowed) { if (pair[0] == from && pair[1] == to) { return true; } } return false; }

这段代码用canTransit方法定义了所有合法流转路径，update时在 WHERE 条件里带上order_status = current，这是乐观锁思路在状态机上的应用——如果两个请求同时读到同一状态，只有一个能更新成功，另一个rows为 0 说明状态已被别人改掉，直接报错。这是 Java 面试常考的「CAS 思想」在业务代码里的落地，比背八股文里的概念有用得多。

3.2 库存防超卖的两层方案：数据库行锁兜底 + Redis 预扣

民宿房源的特点是“同一库存、多日期同时售卖”，一个订单跨多个晚上时，必须所有日期都扣减成功，订单才能创建，否则应整体回滚。数据库层面的防超卖，核心是一条带条件的 UPDATE 语句：

@Update("UPDATE inventory_plan SET booked_count = booked_count + #{count}, version = version + 1 " + "WHERE room_type_id = #{roomTypeId} AND stay_date = #{stayDate} " + "AND booked_count + #{count} <= total_count") int tryLockInventory(@Param("roomTypeId") Long roomTypeId, @Param("stayDate") LocalDate stayDate, @Param("count") Integer count);

这条 SQL 的巧妙之处在于把检查逻辑放进了 UPDATE 的 WHERE 子句。booked_count + #{count} <= total_count不成立时，影响行数为 0，业务侧据此判断库存不足。因为 UPDATE 会行锁，同一时刻只有一个事务能更新同一行，所以不会超卖。这是最简单可靠的兜底方案，值得优先使用。

但数据库行锁有一个性能短板：一个订单跨 7 晚就要锁 7 行，高并发下容易造成锁等待和死锁。常见的优化方案是在数据库之前加一层Redis 预扣，用 Lua 脚本保证原子性。以下是一个可用的 Lua 扣减脚本：

local keys = KEYS local values = ARGV local count = tonumber(values[1]) for i = 1, #keys do local current = tonumber(redis.call('GET', keys[i]) or '0') if current + count > total_count then return 0 end end for i = 1, #keys do redis.call('INCRBY', keys[i], count) end return 1

Java 侧通过 Spring Data Redis 的DefaultRedisScript调用这个脚本。Redis 预扣成功后进入业务逻辑，订单创建成功则保留扣减，失败则用相反脚本回补。这套流程的关键是Redis 只做前置校验和流量削减，数据库仍需兜底——Redis 万一宕机或数据丢失，数据库层照样能拦截超卖。

3.3 缓存一致性：延迟双删与版本号对比

民宿管理系统的房态查询是高频读操作，特别是房态日历页，一次要渲染 30 天的库存状态。常见做法是把「房型 + 日期」的库存余量缓存到 Redis，key 格式设计为inventory:{roomTypeId}:{date}，value 直接存剩余房间数。

缓存和数据库的一致性是绕不开的坑。最实用的方案是延迟双删：更新数据库之前删除缓存，更新数据库之后，隔几百毫秒再删一次。为什么要删两次？因为第一次删除后，如果有请求在数据库更新完成前把旧值写回缓存，第二次删除就能把那个脏数据清掉。实现如下：

public void updateInventory(Long roomTypeId, LocalDate date, Integer count) { String key = "inventory:" + roomTypeId + ":" + date; redisTemplate.delete(key); try { // 执行数据库更新 inventoryPlanMapper.updateBookedCount(roomTypeId, date, count); } finally { // 延迟双删：确保并发读不会把脏数据写回缓存 scheduleDelayDelete(key, 500); } } private void scheduleDelayDelete(String key, long delayMs) { CompletableFuture.delayedExecutor(delayMs, TimeUnit.MILLISECONDS) .execute(() -> redisTemplate.delete(key)); }

延迟双删并非银弹，它依赖“读请求把数据写回缓存”的耗时小于延迟时间，所以延迟时间一般设置 500ms 到 1s。更严格的方案是用 Redis 的 version 字段做对比：缓存 value 中额外存一个版本号，每次更新数据库时把 version 也更新，读请求写回缓存前对比版本号，不一致则丢弃。这个思路在数据一致性要求更高的订单场景中会用到。

3.4 分布式锁在支付回调中的正确用法

民宿系统的支付回调是一个需要细抠的场景：支付宝或微信回调可能重复通知，如果回调处理逻辑没有幂等保护，就会造成重复入账、重复改状态。这里引入分布式锁需要注意，锁的对象是订单号而非整个回调方法，否则所有订单的支付回调会串行化。

public void handlePayCallback(String orderNo) { String lockKey = "lock:order:" + orderNo; boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(10)); if (!locked) { throw new BizException("订单正在处理中，请勿重复提交"); } try { // 双重检查：锁拿到了，还要看订单状态是否已经是已支付 BookingOrder order = orderMapper.selectByOrderNo(orderNo); if (order.getOrderStatus() == 1) { return; } // 更新订单为已支付 changeOrderStatus(order.getId(), 1); } finally { redisTemplate.delete(lockKey); } }

setIfAbsent加过期时间是一个原子操作，能防止锁忘记释放导致的死锁。拿到锁之后仍然要检查订单状态，这个「二次检查」是分布式锁使用中最容易被忽略的细节——锁只保证互斥，不保证幂等，真正保证幂等的是状态检查。这个知识点在 Java 面试中几乎必考，热词检索里的「java动态代理」「java八股文」都没这个场景来得实在。

4. 部署与参数：一台 2 核 4G 服务器也能跑稳的 Java 后端

4.1 环境准备与 MySQL/Redis 的参数初始化

民宿管理系统属于中小型项目，不需要一开始就上微服务。一台 2 核 4G 的云服务器、一个 MySQL 8.0、一个 Redis 6.x，完全跑得动。环境准备阶段有几个参数值得调整，比默认配置更能抗住小规模并发。

MySQL 方面，max_connections默认是 151，对民宿系统够用，但innodb_buffer_pool_size默认 128M 偏小，建议调到物理内存的 50% 左右。2G 内存的机器可以设为 1G：

[mysqld] innodb_buffer_pool_size = 1G max_connections = 200 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1

Redis 方面，关闭持久化反而更稳。民宿系统的库存数据以数据库为准，Redis 只是缓存和锁，用AOF或RDB都会引入额外的磁盘 I/O。配置如下：

save "" appendonly no maxmemory 512mb maxmemory-policy allkeys-lru

save ""表示禁用 RDB 快照，appendonly no表示关闭 AOF。这里想强调的是，控制台输出的慢查询日志长度会直接影响排错效率——long_query_time设为 1 秒，配合后文的压测报告，能把“哪条 SQL 是性能瓶颈”一眼定位。

4.2 Spring Boot 打包与多环境配置分离

Spring Boot 项目用 Maven 打包时，通常需要区分开发环境和生产环境。推荐的做法是使用application.yml作为主配置，再用application-dev.yml和application-prod.yml做环境差异化配置。关键点是数据库密码等敏感信息不要写死在 yml 里，通过环境变量注入：

spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/bnb?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: ${DB_USER} password: ${DB_PASSWORD} redis: host: ${REDIS_HOST} port: 6379

打包命令是标准的 Maven 命令，但有一个参数必须注意——跳过测试：

mvn clean package -DskipTests -Pprod

-Pprod激活生产环境配置，-DskipTests跳过单元测试，避免测试代码连接本地数据库导致打包失败。打包完成后，target/目录下生成的bnb-web.jar就是可交付的产物。给 JAR 包的启动参数时，JVM 内存设置要匹配 2G 的实际可用内存：

java -Xms512m -Xmx1024m -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -jar bnb-web.jar --spring.profiles.active=prod

-Xms512m表示初始堆大小，-Xmx1024m表示最大堆，二者不等可以减少运行期堆扩容带来的性能波动。G1 垃圾回收器在 JDK 11+ 是默认选项，显式指定MaxGCPauseMillis=200是为了控制单次 GC 停顿时间——民宿系统的订单创建链路中有分布式锁和 Redis 操作，如果因为 Full GC 停顿导致锁超时释放，会平白多出很多“系统繁忙”的报错。这是「java环境变量配置」和「java安装」都没覆盖到的实战细节。

4.3 Nginx 反向代理与 HTTPS 证书配置

Java 后端默认跑在 8080 端口，前端通过 Nginx 做反向代理。Nginx 配置文件的 server 块里，除了常规的proxy_pass，还需要处理前端路由的 history 模式：

server { listen 443 ssl http2; server_name bnb.example.com; ssl_certificate /etc/nginx/ssl/bnb.pem; ssl_certificate_key /etc/nginx/ssl/bnb.key; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { root /var/www/bnb-frontend; try_files $uri $uri/ /index.html; } }

try_files $uri $uri/ /index.html这一行是 Vue 或 React 前端路由刷新时页面不丢的关键。Nginx 层面还有一个参数值得注意，keepalive_timeout默认是 75 秒，如果前端页面有长轮询需求，建议调低到 10 秒以内，避免连接数被迟迟不释放的闲连接占满。

4.4 日志采集与生产排错：别只在控制台看报错

生产环境排错和本地开发完全两回事。Java 进程崩溃前几秒发生了什么，只能靠日志回答。Spring Boot 默认的日志配置只输出到控制台，进程一重启就没了。推荐用logback-spring.xml把日志落盘，并按天滚动：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/bnb/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/var/log/bnb/app.%d{yyyy-MM-dd}.log.gz</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender>

日志格式里必须包含线程名和完整时间戳，这是排查分布式锁超时、回调重复通知等问题的前提。配合grep检索关键字，比如排查支付回调问题时直接看订单号的完整链路：

grep "BNB202506120001" /var/log/bnb/app.log | tail -50

这一步能快速确认请求是从哪个入口进来的、在哪一步抛的异常、最终返回了什么状态码。日志做好了，线上问题的排查时间至少缩短一半。在「php源码」、源码建站这些热词反映的内容生态里，Java 项目一个经常被诟病的点就是日志规范差，民宿管理系统作为设计源码，日志质量是拉开差距的地方。

5. 压测与调优：用 JMeter 验证下单链路，补上 MyBatis 与 JVM 的两块短板

5.1 压测脚本设计：模拟 50 个用户同时抢同一间房

系统跑起来之后，第一件事不是写业务，而是验证防超卖策略是否真的有效。用 JMeter 建一个线程组，50 个线程同时并发下单同一房型，观察订单成功数和数据库库存余量。一个关键参数的设置是「Ramp-Up Period」，设为 0 表示所有线程同时启动，模拟瞬时峰值。线程组内添加 HTTP 请求，指向下单接口：

POST /api/order/create Content-Type: application/json { "roomTypeId": 1001, "checkInDate": "2025-08-01", "checkOutDate": "2025-08-03", "guestName": "压测用户", "guestPhone": "13800000000" }

如果房源总计 5 间，压测结束后数据库booked_count的值必须恰好是 5，订单表里已支付状态的数量也必须是 5，任何大于 5 的结果都说明防超卖链路存在漏洞。再加上 Redis 预扣后，JMeter 的聚合报告里响应时间应该出现明显下降——这是因为大部分请求在 Redis 层就被拦截掉了，真正打到 MySQL 的只有与库存等量的请求。

5.2 MyBatis 慢 SQL 分析：从 XML 到索引缺失去定位

压测结束后，MySQL 慢查询日志会列出所有超过 1 秒的 SQL。民宿系统常见的性能瓶颈有三个：一是订单列表查询没走索引，二是库存更新语句的 WHERE 条件没有命中唯一索引，三是分页查询在大偏移量时性能骤降。第三个问题最容易踩坑，比如查看某房源下第 100 页的订单记录，SQL 可能长这样：

SELECT * FROM booking_order WHERE room_type_id = 1001 ORDER BY create_time DESC LIMIT 990, 10;

LIMIT 990, 10意味着数据库要扫描前 1000 行再丢弃前 990 行，这就是深分页问题。优化方案是改成基于游标的分页，用上次查询最大 ID 作为查询条件：

SELECT * FROM booking_order WHERE room_type_id = 1001 AND id < #{lastId} ORDER BY id DESC LIMIT 10;

因为主键索引本身就是有序的，id < lastId直接走主键索引，查询代价恒定。MySQL 5.6+ 本身对LIMIT分页也有优化，但实现深度分页时，这种「键集分页」方式最可靠。MyBatis 源码中PageHelper插件生成的 COUNT 查询在联合索引场景下可能失真，这也是为什么我建议核心列表查询手动写 SQL，而不是完全依赖分页插件。

5.3 JVM 调优的实用检查清单

应用运行一段时间后，通过jstat和jmap观察 JVM 状态。民宿系统的对象特点是短生命周期请求多（下单、查询、支付回调），Young GC 会比较频繁。如果观察到 Full GC 次数持续上涨，优先检查堆内存配置是否有问题，而不是急着调 GC 参数。

jstat -gcutil 12345 1000 10

这个命令每秒输出一次 GC 统计，持续 10 次。FGC列的数字如果每次采样都在增长，说明堆中出现了无法被回收的常驻对象，最可能的原因是把大对象直接放进了缓存或者线程池没有正确关闭。这时用jmap -dump导出堆转储文件，再用 MAT 分析主导内存的对象类型：

jmap -dump:live,format=b,file=/tmp/bnb_heap.hprof 12345

一个隐蔽的 JVM 陷阱是G1在 JDK 11 下的MaxGCPauseMillis目标设置过小（比如 50ms），导致 GC 频繁尝试满足目标而额外触发 mixed GC，反而增加 CPU 开销。对于民宿系统这种请求量级，200ms 是更务实的目标。

5.4 数据一致性验证：一个可复现的压测后核对方法

压测做完不代表完事，还需要验证数据一致性。民宿系统的账务逻辑简单，核对公式如下：

-- 全部已支付订单的间夜数（入住到退房的日期差累加） SELECT SUM(DATEDIFF(check_out_date, check_in_date)) AS paid_nights FROM booking_order WHERE order_status = 1;

理论上，这个值必须等于所有相关日期的库存计划表里booked_count的总和。两边对不上，说明要么订单状态更新和库存扣减不在同一事务里，要么缓存回补逻辑出了偏差。这个核对过程不需要额外的工具，一条 SQL 就能完成，是压测后最值得养成的习惯。

更严谨的做法是在核心的「创建订单 + 扣减库存」方法上标注@Transactional，并且注意传播级别一定要用默认的REQUIRED。如果把订单插入和库存更新分到了两个 Service 方法里，就要小心事务的边界——只给调用方方法加事务注解，而库存更新方法自己也有事务注解，就会出现事务嵌套的问题，内层事务异常可能不会触发外层回滚。这是 Java 面试常客「事务传播行为」在真实项目中的具体案例。

民宿管理系统的价值不在于它有多复杂，而在于它把所有电商系统都会遇到的「并发扣减、状态流转、缓存一致性」问题，压缩在了一个小到可以读完的代码库中。读源码的时候，优先读三条线：订单状态机对应的changeOrderStatus方法、库存防超卖的tryLockInventorySQL、支付回调的幂等处理链。把这三处弄透，比把全部代码读完更有收获。

本文还有配套的精品资源，点击获取