在一次公司年会项目中，我们接到了一个看似平常的任务：开发一个抽奖系统。但需求方轻描淡写地加了一句：“员工名单文件可能有几十万条，甚至上百万。”并且抽奖过程要公平、高效，不能卡顿。传统的ORM逐条保存、全表查询瞬间行不通了。这次我们就来完整复盘，如何基于JPA（Spring Data JPA），亲手打造一个能扛住大文件冲击的抽奖系统。
一、系统需求与核心挑战
抽奖系统的基本功能谁都懂：上传参与人员名单、配置奖品、随机抽取获奖者。但结合“大文件”场景，痛点立刻浮出水面：
- 导入性能：几十万条Excel或CSV数据，如果使用JpaRepository的
save()逐条插入，每条都要开启事务、处理一级缓存，速度慢到难以接受，甚至会因为连接超时而崩溃。 - 随机抽取效率：当参与人数达到百万级，一句
ORDER BY RAND()+LIMIT可能会让数据库CPU飙红，甚至锁表。 - 防重复与并发安全：在高并发环境下，如何保证一个人只能中奖一次？单纯依靠Java代码控制，集群部署时会出现状态不一致。
- 内存溢出风险：不能把上百万条数据一次性加载到JVM内存中进行随机，否则OOM（OutOfMemory）会随时光临。
这些痛点，恰好是JPA使用中最容易被忽视，却又最能体现架构能力的地方。接下来，我们逐个击破。
二、JPA大文件导入的艺术：从“龟速”到“闪电”
面对几十万条数据的导入，我们首先想到的是JPA的批量处理能力。很多人以为JPA只能简单save，但实际上结合底层JDBC，完全可以实现高性能批量插入。
2.1 放弃逐条save，拥抱批量插入
Spring Data JPA的saveAll方法默认仍然是循环调用EntityManager的persist，并不会自动开启JDBC批处理。我们需要在application.properties中显式配置：
spring.jpa.properties.hibernate.jdbc.batch_size=1000spring.jpa.properties.hibernate.order_inserts=truespring.jpa.properties.hibernate.order_updates=true
然后手动控制批量大小与事务：
伪代码逻辑：将解析出的参与者列表按1000条分组，每组在一个事务内执行，每批完成后清除EntityManager缓存，防止一级缓存膨胀导致内存溢出。
@Transactional
public void batchInsert(List list) {
int batchSize = 1000;
for (int i = 0; i < list.size(); i++) {
entityManager.persist(list.get(i));
if (i % batchSize == 0 && i > 0) {
entityManager.flush();
entityManager.clear();
}
}
entityManager.flush();
entityManager.clear();
} 通过这种方式，插入速度从之前的每秒几十条提升到每秒数千条甚至万条，极大缩短了导入时间。
2.2 主键生成策略的选择
批量插入时，IDENTITY主键生成策略会让JDBC驱动程序无法批量优化，因为每次插入后都需要返回生成键。我们应当选用SEQUENCE（如PostgreSQL）或TABLE策略，或者干脆使用UUID类型的String主键，在业务层预先生成，从而让批量插入真正生效。
三、百万数据下的极速随机抽取
导入性能解决了，抽奖环节才是系统的灵魂。当参与人数达到100万，我们需要从中随机抽取10位一等奖，100位二等奖。如果用JPA的ORDER BY function('RAND')或者原生的ORDER BY RAND()，数据库需要为每一行生成一个随机值再排序，成本极高。更聪明的做法是：
3.1 基于ID范围的随机抽取
提前统计出参与者ID的最小值和最大值（非连续也可以采用其他策略）。然后利用分页查询与随机ID起点：
- 计算随机ID起点：
Random random = new Random(); long randomId = minId + random.nextInt(maxId - minId + 1); - 使用JPA Derived Query：
PagefindByIdGreaterThanEqualOrderByIdAsc(long startId, Pageable pageable);
从随机ID开始取一页，如果页面不足再循环补充。这样避免了全表随机排序，利用主键索引进行高效范围扫描，数据库负载极低。
3.2 抽奖池状态管理：一张表锁住“已抽中”
为了实现防重复中奖与 并发安全，我们设计了一个轻量的抽奖记录表，包含参与者ID、奖品ID、抽奖时间等字段，在参与者表和奖品表之间建立唯一约束（参与者ID + 奖品类型）。在执行抽奖时，先通过JPA的existsByParticipantIdAndPrizeType快速校验，或者直接利用INSERT IGNORE ...（数据库特性）或结合@Version乐观锁控制。不过更稳妥且简洁的方式是使用 Redis分布式锁 或数据库行级锁（select for update），确保同一参与者不会被并发抽中同一个奖品类型。
我们最终采用数据库层面的方案：在给用户分配奖品时，使用一条自定义SQL：INSERT INTO winner_record (...) SELECT ... WHERE NOT EXISTS (...)，利用JPA的@Modifying配合@Query，将判断和插入合并为一个原子操作，保证幂等性，完美避免了并发问题。
四、系统架构与扩展思考
整个系统基于Spring Boot + Spring Data JPA构建，前端采用Vue开发，异步上传文件后，后端开启独立线程异步解析导入，通过WebSocket或轮询返回进度。抽奖环节设置为接口幂等，可重复刷新但结果不变。核心分层清晰：Controller负责参数校验，Service层封装业务逻辑，Repository只承担数据访问，复杂的统计和随机逻辑下沉到数据库查询或存储过程。
为了应对未来更大规模的数据，我们还预留了分库分表方案，通过ShardingSphere-JDBC与JPA整合，按参与者ID哈希分成128张表，保证单表数据量不过大。同时，引入本地缓存与Redis存放已中奖黑名单，加速重复校验，进一步减轻数据库压力。
五、结语
很多时候，开发者诟病JPA性能差，根源往往在于没有用对方式。通过本文的案例可以看出，只要合理配置批量、善用分页随机查询、设计合理的主键与索引，并巧妙结合原生SQL的原子操作，Spring Data JPA完全可以胜任大文件抽奖系统这类高吞吐、高并发场景。希望这个实战分享能为你的项目带来新的思路，让JPA不再是性能瓶颈的替罪羊，而是得心应手的利器。