Java重构会展服务平台：状态机、并发控制与数据库优化实践

简介：基于Java的会展服务平台设计与实现文档，内容覆盖平台需求、设计目标、设计方案及实现技术，面向Java Web方向的高校毕业生或开发者。文档从会展服务管理实际场景出发，围绕管理员与用户两类角色展开，管理员侧涉及个人中心、首页轮播图、用户管理、社团审核、论坛管理、建议留言等模块，用户侧则聚焦帖子管理、社团管理与个人中心，功能划分清晰。方案采用B/S结构，通过Java动态页面设计，后台搭配MySQL数据库，体现了一套完整的Web项目构建路径。资源包仅有1个docx文件，大小约1.79MB，适合在Word中直接阅读，也可作为毕业设计说明书或课程设计参考模板。内容还包括平台的测试过程与结果，便于读者了解从需求到上线的完整闭环，对准备相关课题开题或文档撰写的用户有较强的参考价值。目前已有119人学习下载。

1. 会展服务平台为什么值得用 Java 重做一遍

很多人一听到“会展平台”，第一反应是给展会做一个官网加一个报名表单。但真正让平台产生价值的，并不是宣传页，而是展商、展位、观众、日程四条主线的状态流转：展商要在线挑展位，主办方要审批资质，财务要锁定定金，现场要完成签到和验票。业务规则一旦超过三张表，用页面脚本或低代码平台就很难维护状态一致性，这时 Java 在领域建模、事务控制、并发处理上的积累就体现出来了。

一个可落地的会展服务平台，通常需要同时支撑三类角色：主办方配置展馆和权限，展商走入驻申请和展位预订流程，观众完成注册、预约和入场。三条线在数据层面高度关联，并发压力又集中在展位抢订和预约票发放两个动作上。Java 技术栈的典型打法，是用 Spring Boot 组织接口，用 MySQL 保存业务事实，再用 Redis 解决热点读和秒级锁，这样的设计在后续接入支付、短信通知、人脸识别时也不用推倒重来。下文按一套实践中能直接落地的方案展开。

2. 会展服务平台的 Java 领域建模与模块边界划分

2.1 会展核心实体与状态机设计

会展服务平台里最容易被忽略、却最决定后期维护成本的一样东西，是把所有可能的状态变化收敛成一张明确的状态机。以展位为例，从主办方放出来到最后成交，至少要经历可预订、锁定中、已付款、已确认、已释放五个状态；用户看到的是按钮置灰和文案变化，后端要保证的是状态迁移合法、不允许跳迁。缺少状态机约束的代码，最后都会在某个边界 case 里露出一条绕过的路径。

用 Java 枚举实现状态机，最直接的好处是拿到编译期检查和调用方可读性。通常我会这样写：

public enum BoothStatus { AVAILABLE("可预订"), RESERVED("锁定中"), PAID("已付款"), CONFIRMED("已确认"), RELEASED("已释放"); private final String desc; BoothStatus(String desc) { this.desc = desc; } public String getDesc() { return desc; } public boolean canTransferTo(BoothStatus target) { return switch (this) { case AVAILABLE -> target == RESERVED || target == RELEASED; case RESERVED -> target == PAID || target == RELEASED; case PAID -> target == CONFIRMED || target == RELEASED; default -> false; }; } }

这段代码把每个来源状态允许到达的目标状态显式声明出来，后续在服务层调canTransferTo，所有非法迁移都会被拦截在业务逻辑之外，这正是设计模式中状态模式在 Java 项目里最常见的落点。值得提醒的是：状态判断不能只写在 Service 层，还必须体现在 Mapper 的UPDATE语句WHERE条件里，否则高并发下两个请求同时读到AVAILABLE，各自更新会造成状态覆盖。

从领域对象看，平台至少需要这些核心实体：展会（Exhibition）描述一场展会的基本信息；展馆（Hall）、展位（Booth）描述物理资源；展商（Exhibitor）和申请单（Application）描述展商与展位之间的关系；观众（Visitor）与预约单描述入场侧的预约关系。申请单是展商侧审批链的主角，自身也有草稿、已提交、审批中、已通过、已驳回、已取消这些状态。把展位状态和申请单状态分开建模，比混在一个字段里要容易维护得多，因为两者变化的触发人和业务含义完全不同，混在一起后审批驳回还要回退展位状态，代码会变成一张到处 case 的大网。

状态迁移关系适合用一张表固化在文档和代码注释里，评审和转交时都比较直观：

2.2 Maven 多模块工程按什么规则切分

会展业务的量级通常在百万级曝光、数万展商，这种规模并不需要微服务化，但把所有类堆在一个工程里也不好维护。我一般按照依赖方向拆成五个模块：

exhibition-parent ├── exhibition-common // 工具类、常量、统一返回值封装 ├── exhibition-domain // 实体类、枚举、状态机校验 ├── exhibition-dao // MyBatis Mapper 接口与 XML ├── exhibition-service // 业务服务、事务边界、领域服务 └── exhibition-web // Controller、DTO、参数校验、全局异常

模块之间的依赖方向是单向的：web 依赖 service，service 依赖 dao 和 domain，common 被所有模块引用。这个切法成立的前提是业务没有跨模块的循环依赖；一旦出现服务互相调用的情况，先停下来想想是不是领域划分错了，而不是直接开一个相互引用。会展平台里最容易出现循环引用的地方，是展位申请和财务订单：申请单要查支付结果，支付单又要回写申请单状态。处理方式是把支付结果作为领域事件回传给申请单，而不是让两个 Service 直接互调。

另外需要注意，exhibition-domain模块里只放纯 Java 对象和枚举，不要引入 MyBatis 或 Spring 的注解；exhibition-dao里的 Mapper 返回的是 domain 里的实体，而不是exhibition-web里的 DTO。这样后续做接口升级时，变动范围被控制在 controller 层，不会出现改一个字段名影响全部模块的情况。

2.3 领域对象和数据库实体要不要分开

很多团队在会展这类管理系统里习惯让实体类跟表字段完全对齐，业务方法直接写在实体类上。对中小型项目这样做问题不大，但到了审批链、支付、签到多个模块协同的阶段，领域对象和数据库实体分开写会更稳。原因很简单：表结构是为存储和索引设计的，领域对象是为业务行为设计的，两者变化频率不同。

以展位对象为例，数据库里一个 booth 表可能包含内部备注、外部备注、字典码等多个字段，这些在领域对象里可以直接隐藏。领域对象只保留id、exhibitionId、boothNo、area、price、status、version这些真正参与业务的字段，转换工作全部放在 dao 层完成，service 层不感知字段细节。这样做的代价是多写一层映射，收益是业务要求“同一个展位号在不同展会下可以重复出现”时，只需要调整联合唯一键，领域代码完全不用动。

3. 基于 Spring Boot 的会展平台核心业务接口实现

3.1 搭建会展服务的最小依赖清单

构建会展平台不需要搭微服务全家桶，最小可运行集合是 Spring Boot Web、MyBatis、MySQL 驱动、Redis 客户端、参数校验。用 Maven 管理依赖时，pom.xml 的关键部分长这样：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>

这组依赖里，MyBatis starter 负责把 Mapper 接口注册成 Spring Bean；Redis 用来做可预订展位列表的缓存和秒级锁；validation 对请求参数做第一层校验。选择 MyBatis 而不是 JPA，主要原因是会展后台有大量按展馆、展位类型、价格区间组合的多条件查询，SQL 直接写在 XML 里更方便做 explain 优化，不需要跟 Hibernate 自动生成的 SQL 较劲。

配置层还需要指定 mapper 扫描路径和驼峰映射：

mybatis: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true

打开underscore-to-camel-case后才有booth_no → boothNo的自动映射。这里要留意，数据库字段是hall_no、booth_no，Java 属性必须是hallNo、boothNo，命名规则一旦不一致，列表查询会查出 null 属性。

3.2 展位抢订唯一性控制：别只靠 synchronized

展位预订是会展平台并发量最高的接口。多个展商同时抢同一展位时，如果只用synchronized包住 Service 方法，单机部署下勉强能用；一旦会展业务常见地用 Nginx 挂多台节点，锁就彻底失效了。正确做法是把并发控制下沉到数据库行锁，用一条条件更新完成状态流转和独占：

@Transactional(rollbackFor = Exception.class) public Long reserveBooth(Long boothId, Long exhibitionId, Long exhibitorId) { int affected = boothDao.casLock(boothId, exhibitionId); if (affected == 0) { throw new BusinessException("BOOTH_BUSY", "展位刚被预订，请刷新后选择其他展位"); } Application application = new Application(); application.setBoothId(boothId); application.setExhibitorId(exhibitorId); application.setStatus(ApplicationStatus.SUBMITTED); applicationDao.insert(application); return application.getId(); }

对应的 Mapper 里这样写 UPDATE：

UPDATE booth SET status = 'RESERVED', version = version + 1 WHERE id = #{boothId} AND exhibition_id = #{exhibitionId} AND status = 'AVAILABLE'

这条 SQL 就是一把行级锁：affected返回 1，说明本次更新真的把可用状态改成了锁定中；返回 0，说明展位状态已经被人改掉，或者展位不属于该展会。这种条件更新比悲观锁SELECT ... FOR UPDATE更轻量，后者在事务期间一直持有行锁，后续审批流程里一旦混入外部接口调用，很容易把数据库连接池打满。

这里的关键点是@Transactional和UPDATE必须在同一个事务内，且事务里不要做远程调用或长时间等待。有人在事务里先SELECT再判断再UPDATE，在读已提交隔离级别下存在竞态窗口，必须改成直接条件更新。如果预订动作后面还要清理 Redis 中对应展位的缓存，建议在事务提交后再删缓存，避免出现旧缓存被新值覆盖的脏读问题。比较规范的写法是通过TransactionSynchronizationManager注册事务提交后的回调，或者直接使用 Spring 的@TransactionalEventListener(phase = AFTER_COMMIT)监听领域事件。

3.3 展商入驻审批链路的接口设计

审批链路包含提交申请、主办方初审、财务确认、最终通过四个阶段。接口设计上我倾向把每个审批动作定义成明确动词，而不是做一个通用化的updateStatus。原因是通用状态更新接口无法约束状态机合法性，任何调用方都可以把已驳回的申请重新改成已通过。

Controller 层给出两个入口：

@PostMapping("/api/applications/{id}/submit") public Result<Void> submit(@PathVariable Long id) { applicationService.submit(id); return Result.ok(); } @PostMapping("/api/applications/{id}/review") public Result<Void> review(@PathVariable Long id, @RequestBody @Valid ReviewRequest request) { applicationService.review(id, request.getApprove(), request.getOpinion()); return Result.ok(); }

提交和审批拆成两个接口：submit 里校验申请单处于DRAFT状态，review 里校验当前状态必须为SUBMITTED或APPROVING，否则直接抛异常。参数校验除了基础的@NotNull，还要检查审批意见长度不超过 500 字；如果涉及驳回操作，意见字段必须非空，方便展商明确知道被拒原因。审批通过后，领域事件触发展位状态从RESERVED变成PAID，这部分逻辑放到 service 层做而不是 Controller，保证事务边界统一。数据库层的 application 表给booth_id加唯一索引，保证一个展位不会被重复提交申请，这是最后一道防线。

4. 会展平台数据库设计与高频查询的 SQL 优化

4.1 库表结构与索引设计实操

会展平台的表结构不要设计成一张大宽表。展位、申请、观众、订单分开建表，通过业务 ID 关联。以展位表为例，推荐这样建表：

CREATE TABLE t_booth ( id BIGINT AUTO_INCREMENT PRIMARY KEY, exhibition_id BIGINT NOT NULL COMMENT '展会ID', hall_no VARCHAR(16) NOT NULL COMMENT '展厅编号', booth_no VARCHAR(32) NOT NULL COMMENT '展位编号', booth_type TINYINT NOT NULL COMMENT '1-标准 2-特装 3-光地', area DECIMAL(10, 2) NOT NULL COMMENT '面积', price DECIMAL(12, 2) NOT NULL COMMENT '价格', status VARCHAR(16) NOT NULL COMMENT 'AVAILABLE/RESERVED/PAID/CONFIRMED/RELEASED', 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, UNIQUE KEY uk_exh_hall_booth (exhibition_id, hall_no, booth_no), KEY idx_exh_status_type (exhibition_id, status, booth_type) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT '展位资源表';

重点说明两个索引的用途：uk_exh_hall_booth保证同一个展会内展厅加展位号不重复，这是业务上的天然唯一键；idx_exh_status_type用组合索引支撑前台列表按展会、状态、展位类型三个条件过滤。经常被漏掉的一点是，状态字段用VARCHAR存英文枚举可读性好，但会占用更多空间且索引体积变大；如果长期只有固定几个值，也可以改成TINYINT加字典表。考虑到系统早期排错方便，通常先保留字符串，中后期再压缩。

应用表、订单表、观众表的字段组织也是同理：

除了审批流程涉及的表之外，会展平台还有明显的读多写少场景：主办方按天看展位预订进展，观众查展会活动日程。这类报表查询适合建几张只读统计表，定时任务每天凌晨汇总，避免白天查询直接压到业务主表上。这一点在数据量超过几百万行后差异非常明显。

4.2 高频查询场景与 explain 排错

会展平台最高频的查询是“某个展会当前还有哪些可预订展位”，要求结果按价格排序，同时带出展位类型、面积、楼层信息：

SELECT id, hall_no, booth_no, booth_type, area, price FROM t_booth WHERE exhibition_id = 101 AND status = 'AVAILABLE' AND booth_type IN (1, 2) ORDER BY price ASC;

数据量上来以后，要习惯在跑这条 SQL 前先查执行计划：

EXPLAIN SELECT id, booth_no, price FROM t_booth WHERE exhibition_id = 101 AND status = 'AVAILABLE' AND booth_type = 1;

观察type列，如果出现ALL说明走了全表扫描；key列为NULL说明索引没被选中。可预订展位列表这种查询，正确的执行路径应该走到idx_exh_status_type上，type是ref或者range。还有一个常见坑是对索引列做函数运算，比如WHERE DATE(create_time) = CURDATE()，这类写法一旦出现，索引直接失效；需要按日期查询时，应该把条件写成create_time >= ? AND create_time < ?的区间形式。

展商侧的“查看我提交过的申请单”使用exhibitor_id + status联合索引，并在列表页做分页。申请单超过十万条后，建议按年度归档到历史表，避免一个索引里膨胀太多已过期数据。归档动作可以做成每月一次的定时任务，只迁移状态为已通过且创建时间超过一年的记录。

4.3 缓存提升可预订展位查询速度的边界

把可预订展位列表放到 Redis 是会展平台的标准优化手段，查询接口读缓存，数据变更后删缓存。缓存 key 建议按展会维度切分，形如booth:available:{exhibitionId}，value 存 JSON 数组。这里有一个容易忽略的坑：删除缓存和数据库更新的顺序不能搞错。正确顺序是更新数据库，再删除缓存；如果反过来了，删除缓存到更新数据库之间的新读请求会把旧值写回缓存，造成长时间脏读。

为了不让缓存逻辑侵入业务代码，通常在读多写少场景使用 Spring Cache 注解：

@Cacheable(value = "booth:available", key = "#exhibitionId + ':' + #boothType") public List<Booth> listAvailableBooths(Long exhibitionId, int boothType) { return boothDao.listAvailableBooths(exhibitionId, boothType); }

@Cacheable的 key 里要带上 boothType，因为同一个展会的可预订列表会根据展位类型返回不同内容，key 缺了这个维度就会出现串数据。会展平台在开展前两周访问量最高，把这些热门展会的可预订列表提前按 key 做缓存预热，能显著减少高峰期的数据库读压力。缓存过期时间建议五分钟到十分钟，展会信息变更频率不高，这个时长足够撑住峰值，也不会过多占用 Redis 内存。

5. 展位抢订场景的压测流程与连接池调参

5.1 用 JMeter 验证并发下不超卖

写完展位预订接口，第一步不是上生产，而是在测试环境搭一套最小压测。用 JMeter 建立线程组，设计 100 个线程、每个线程循环 20 次，只压多个人抢同一个 boothId 的接口。压测后观察三件事：数据库里该展位的状态是否变为RESERVED；是否出现超过一条 application 记录挂到同一 booth_id；日志里BOOTH_BUSY的数量是否等于并发失败请求数。第三点最容易判断超卖是否被拦住，因为被业务异常拦截的请求不会产生脏数据。

5.2 锁与事务的边界常踩的两个坑

第一个坑是把 Redis 分布式锁和数据库更新放在同一个事务方法里，锁在事务提交前释放，导致另一个线程拿到锁后读到的还是旧状态。第二个坑是事务嵌套：审批链路里调用了外部短信服务，外部服务缓慢会让事务迟迟不提交，数据库连接被占满。会展平台的审批、支付这类操作，外部调用务必放到事务外层，事务内只保留状态更新和数据库写入。

5.3 HikariCP 与业务线程池参数设定

HikariCP 默认连接池maximum-pool-size是 10，在开展前一周的流量高峰下明显偏小。按单机并发估算：接口平均耗时 50 毫秒，单节点峰值 1000 TPS，稳态连接大约需要 50 个，池上限设在 80 到 100 比较合适。connection-timeout设为 30000 毫秒，避免瞬时峰值把连接请求全部打挂。业务线程池同样不能放任默认值，用@Async做短信通知、导出发票时，单独声明一个 ThreadPoolTaskExecutor，核心线程 16，最大线程 32，队列长度 200，拒绝策略用CallerRunsPolicy，让过多任务退回调用线程而不是直接丢弃。

spring: datasource: hikari: maximum-pool-size: 80 minimum-idle: 10 connection-timeout: 30000

这套配置配合状态机枚举、条件更新、事件解耦几个关键点，可以保证会展平台在流量高峰下不超卖、不拖垮数据库。实际压测时在 JMeter 里对返回码做断言，只有 HTTP 200 且响应体里 code 字段为 0 才算成功，最终拿到的是一个明确的有效吞吐量数字，而不是被超时请求拉高平均耗时的假象。如果是把会展服务平台写进简历的 Java 面试场景，能从状态机设计讲到连接池参数计算，已经足够覆盖面试八股文里并发和事务这两类高频考点。

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