基于Java SpringCloud+SSM的分布式演唱会抢票系统高并发架构实践

“基于JavaSpringCloudSSM的分布式演唱会抢票系统”这个命题我见了太多次很多人以为把SpringCloud拆几个微服务、Redis存个库存就能交差结果一压测全露馅超卖、同座票重复卖出、库存扣减对不上账、下单接口直接被刷爆。这篇文章我把这套系统的核心思路、踩坑实录和可复现的关键实现一次性讲透适合正在做毕业设计、求职项目或者想把单体抢票重构为分布式方案的开发者对照参考。先说明白这系统到底解决什么问题。演唱会的“抢票”和普通电商下单完全是两种节奏一场热门演出开票瞬间可能涌入几十万请求但真正库存可能只有几万张。系统要做的不是“能下单”而是“在极端流量下还能保证不超卖、不重复、响应快、数据最终一致”。Java SpringCloud SSM这套组合放在这里指的是SSMSpring SpringMVC MyBatis负责业务层的数据处理和持久化SpringCloud承担服务拆分、注册发现、网关路由和远程调用再配合Redis、消息队列等中间件完成高并发下的流量控制和库存管理。1. 项目整体设计与技术选型1.1 为什么要用分布式而不是继续堆单体先说绝大多数人踩的第一道坎一开始用单体架构做抢票改造时才发现崩塌点根本不是代码而是数据库。单体架构里所有请求打到一个应用再打到库里连接数一满整个系统全部阻塞。我以前帮人优化过一套单体抢票压测到两千并发MySQL连接池直接打穿后面排队的用户连登录都进不去SQL层面全是“too many connections”。这就是典型的“单点瓶颈”不是调优能解决的而是架构层面必须拆分。拆分为分布式之后第一收益是把压力分散到多个服务实例上网关层、业务层、库存层各管一段。比如用户登录请求走用户服务抢票请求走订单服务库存扣减走库存服务各自独立部署、独立扩缩容。第二收益是隔离故障某个服务挂了不至于牵连整站。第三收益是扩展性开票前可以动态扩容订单服务实例数活动结束后再缩容成本可控。但要注意分布式不是银弹它带来了新的问题服务间如何互相发现配置怎么统一管理请求如何路由到正确的服务远程调用失败了怎么处理分布式事务怎么保证这些正是SpringCloud要回答的。所以这个项目的技术选型逻辑不是“用酷炫技术堆一堆”而是每加一个组件都对应一个真实痛点。1.2 技术栈组合的合理搭配这个项目里SSM和SpringCloud的职责边界要划清楚。SSM是基础开发框架Spring负责依赖管理和事务SpringMVC负责Web层请求映射MyBatis负责SQL操作数据持久化。SpringCloud作为微服务治理层提供注册中心我常用Nacos、服务网关Spring Cloud Gateway、远程调用OpenFeign、熔断降级Sentinel或Resilience4j。具体到一次购票请求链路是这样的前端请求先打到Spring Cloud Gateway网关网关做限流和路由把请求转发到订单服务订单服务先查Redis里预扣的库存配额再调用库存服务的接口确认扣减最后异步通过消息队列通知第三方支付服务生成支付单。整套链路里SSM相当于每个微服务内部的“地基”SpringCloud则是把各个“地基”串起来的高速网。还有一个常见误区把Redis和消息队列当成可选组件。在抢票场景里它们是必需品不是装饰品。Redis解决的是库存的原子扣减和热点数据的读性能问题消息队列解决的是高峰期请求削峰和解耦问题。少了这两样光靠微服务拆分数据库一样会被压垮。2. 核心业务模块拆解与数据模型2.1 用户、演出、场次与票档任何票务系统都不能绕开四类基础数据用户、演出、场次和票档。用户表不用多说核心是用户ID、手机号、登录态凭证。演出表存的是演出的基础信息比如艺人、演出名称、海报、说明文字。场次表非常关键一场演唱会通常在同一天有多个场次或者多城市巡演有不同的场次每个场次独立对应一个演出。票档表则描述价格和区域比如内场A区、看台B区每个票档关联到具体场次。我见过很多项目把场次和票档混在一张表里字段设计极度混乱最后统计哪个票档还有多少余票时只能靠foreach循环算性能惨不忍睹。正确的做法是场次表与票档表做一对多关联票档表里存场次ID、票档名称、原始总票数、已售数量、价格。库存则不要直接冗余在票档表的正数字段上“裸扣”而是放到Redis里以票档ID为key来做原子操作这一点后面专门讲。另外有一个细节如果做的是真正可落地的系统还要考虑“区域座位图”。简化方案是票档级别不具体到座位号只控制每个票档的库存总数进阶方案是精确到座位号那就要维护座位表场次ID、区域ID、行号、列号、座位状态并且要考虑两个同时选中同一座位的并发冲突。毕业设计和工程演示通常用票档级库存就够了但你要知道自己在这个维度上做了“简化取舍”面试被问到时能讲清楚为什么。2.2 订单表与流水表设计订单表是系统里数据一致性要求最高的地方。核心字段包括订单号必须唯一、用户ID、场次ID、票档ID、数量、单价、总金额、订单状态、创建时间、支付截止时间。订单状态建议用状态机管理已创建、待支付、已支付、已取消、已退款、已失效。除了订单表强烈建议再加一张库存流水表记录每一次库存扣减和回补的操作。字段包括流水号、票档ID、订单号、操作类型预扣、确认扣减、回补、操作数量、操作前库存、操作后库存、操作时间。这张表的价值在于对账和排查问题一旦出现超卖或者重复扣减可以通过流水表回放整个操作序列定位是哪一步出现了并发冲突。很多人做项目时嫌流水表多余但真正上线后没有它排查数据问题就是大海捞针。订单号和普通主键ID要有区分。主键ID可以自增或雪花算法生成但对用户暴露的订单号一定要短、唯一、不容易被枚举常用方案是“日期 随机数 校验位”或直接用预生成的随机字符串。不要直接把自增ID暴露给前端会被爬虫遍历出全站的订单数据。3. 分布式高并发抢票的核心实现3.1 库存预扣与Redis原子操作抢票系统最容易犯的错误是用户点下单时直接 UPDATE 库存表 SET stock stock - 1。在低并发下没问题高并发下同一行记录被多个事务同时更新会出现超卖——多个请求都读到了库存为1然后都执行扣减最后都通过校验。数据库的行锁虽然最终能保住一致性但会让大量请求排队等待系统吞吐量急剧下降。更合理的方案是在Redis里做库存预扣。开票前用定时任务或管理后台操作把本场次每个票档的库存同步到Redis比如用 String key ticket:stock:{ticketTypeId}再用Redis的 DECR 命令做原子扣减。DECR本身就是原子操作多个并发请求同时执行也不会超扣。扣减前可以先判断当前值是否大于0用 Lua 脚本把“判断库存是否足够 扣减”两个操作合并成一个原子脚本这是标准的做法。下面是一段我在项目中常用的Lua脚本示例local stock tonumber(redis.call(get, KEYS[1])) if not stock or stock 0 then return -1 end redis.call(decrby, KEYS[1], ARGV[1]) return stock调用时把票档库存的Redis key和购买数量传进去。返回-1说明库存不足直接返回“已售罄”否则进入下一步。这套方案的好处是单次扣减操作的耗时在毫秒级Redis单机就能扛住很高的QPS数据库层只在最终确认时扣减一次压力小得多。3.2 消息队列削峰与订单异步处理抢票高并发场景下如果把所有请求都同步打到订单服务和数据库峰值流量会瞬间把后端打挂。这也是“削峰”这一概念的实际意义。我的做法是订单服务接收请求后在网关层或服务入口处做初步限流通过的请求把“创建订单”的任务投递到消息队列比如RabbitMQ或RocketMQ后端消费者按自己能承受的速率去处理下单逻辑。这里有个容易踩的坑不是把原始请求直接投到队列就完了而是要设计好队列的消费模型。我自己常用的是“一个场次一个虚拟队列”也就是消息的routing key带上场次ID或票档ID这样同一个票档的订单可以被串行消费或按顺序处理降低库存扣减顺序错乱的概率。如果所有场次混在一个队列里多个消费者并行消费同一个票档的订单时会大大增加并发冲突的概率。异步处理还带来一个体验问题用户点击抢票后不能傻等一个同步结果。前端在提交抢票请求后应该轮询或通过WebSocket接收“抢票结果通知”页面可以展示“正在排队中”的中间状态。这里要设计一个“结果查询”接口订单服务在处理完消息后将状态回写数据库和Redis用户端的查询接口通过订单号或一个临时排队标识去获取最新状态。3.3 限流、防刷与分布式锁高并发系统的第一步不是处理业务而是把无效流量挡在外面。限流我习惯在网关层做Spring Cloud Gateway结合Sentinel可以配置按接口、按参数、按用户维度的限流规则。比如对“下单接口”做每秒每用户最多2次的限制对“查询接口”放宽到每秒10次。限流的目的不是拒绝所有用户而是把流量整形到后端能承受的区间让真实用户有机会挤进来。防刷要从两个视角考虑同一用户短时间内重复提交同一IP或设备短时间内大量请求。前者可以用用户ID 接口维度做计数限流后者可以在网关层做IP维度的滑动窗口限流。正经项目还会加验证码或滑块抢票场景下用“静默验证”比强制验证码体验更好比如在客户端收集一些设备指纹信息后端对异常特征做拦截。还要注意分布式锁的使用场景别滥用。在Redis做库存预扣之后数据库层的“订单确认”并不需要再对库存行加悲观锁否则并发瓶颈又回到数据库。分布式锁最典型的使用场景是针对某个用户同一场次只能下一单、某个票档的促销开关只能被一个服务实例修改这类“低频但必须互斥”的操作。另外使用Redis分布式锁务必设置合理的过期时间防止锁持有者崩溃后锁一直不释放导致后续请求全部阻塞。4. 实操过程与关键环节实现4.1 服务拆分与SpringCloud基础环境搭建实操第一步是把Maven多模块工程建好。我习惯按业务域拆分模块而不是按技术层拆分。也就是说不要拆一个“controller模块”一个“service模块”而是拆出用户服务user-service、演出服务show-service、库存服务inventory-service、订单服务order-service、支付服务payment-service。每个服务都是独立的SpringBoot应用内部再用Controller、Service、Mapper分层。注册中心我用Nacos因为它同时承担服务注册发现和配置中心两个角色省去再搭一套配置管理组件。启动Nacos后在每个服务的配置文件中注册到Nacos并开启服务发现server: port: 9101 spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848服务间的远程调用用OpenFeign。比如订单服务需要调用库存服务扣减库存就在订单服务中定义一个Feign客户端接口映射到库存服务的扣减接口FeignClient(name inventory-service, path /inventory) public interface InventoryClient { PostMapping(/deduct) RBoolean deduct(RequestBody DeductRequest request); }这里要注意Feign调用超时时间的设置。抢票高峰期服务可能变慢默认的1秒超时几乎必然触发熔断。我一般将连接超时设为3秒读取超时设为10秒同时开启重试但要注意如果扣减接口不是幂等的重试可能导致重复扣减所以要么在扣减操作上做幂等处理比如同一个业务流水号只允许扣一次要么关闭重试并配合业务层的补偿机制。4.2 抢票核心链路完整演示下面把一条完整抢票链路的代码逻辑梳理出来。前端调用/order/create接口参数包含场次ID、票档ID、购买数量、用户标识。网关层限流之后请求进入订单服务的Controller第一步是校验基础参数和用户登录态第二步从Redis获取票档库存并执行Lua脚本预扣第三步扣减成功后组装订单消息发送到MQ第四步立即返回“排队中”状态给前端。MQ消费者监听到订单消息后开始真正的订单创建RabbitListener(queues order.create.queue) public void onCreateOrder(OrderCreateMessage message) { // 1. 幂等校验根据业务流水号判断订单是否已存在 // 2. 创建订单主记录状态为待支付 // 3. 调用库存服务确认扣减更新数据库库存 // 4. 生成支付单并推送到支付服务 }这里必须重点提醒幂等的问题。MQ消息在极端情况下可能被投递不止一次生产者重试、消费者异常后重新入队所以消费者一定要保证幂等。我通常在每个业务操作里带上一个全局唯一的业务流水号bizNo在数据库建立唯一索引消费前先按bizNo查一次已存在就直接返回。这是做实战项目最常被忽略又最影响可靠性的细节。4.3 数据库层面的最终一致性保障Redis预扣之后数据库的库存最终要怎么和Redis对齐我的做法是数据库库存表保留“总库存”和“锁定库存”两个字段。下单预扣对应逻辑就是检查可用库存 总库存 - 锁定库存 0然后锁定库存增加。用户支付成功后锁定库存不变总库存减去购买数量这就是最终一致性回写。用户取消订单或支付超时锁定库存减少把配额释放回可用库存。这个方案最关键的地方在于数据库层面不需要对总库存字段做高频的并发更新大部分压力被Redis扛住数据库只承受低频的“确认”和“回补”操作。对账时可以用库存流水表核对——Redis当前值加上已确认扣减总量应该等于初始库存。我强烈建议在项目里写一个简单的对账Job每小时或每场活动结束后跑一次不一致时发告警这是保证数据可靠性的最后一道防线。5. 常见问题与排查技巧实录5.1 超卖问题前端显示还有票提交时却售罄这个现象几乎每个抢票系统都遇到过。原因主要有两类第一类是前端展示的库存来自缓存没有实时刷新第二类是后端扣减逻辑没有使用原子操作比如先查库存再更新查和更新之间的间隙被其他请求插入。排查思路是先看Redis的库存key是否在所有扣减路径上都是原子操作把所有“判断扣减”逻辑封装到Lua脚本里再看前端轮询库存的接口频率和缓存过期时间把“精确库存”和“展示库存”分离展示库存允许延迟几秒下单时的库存必须以Redis实时值为准。这里补充一个细节扣减库存后即使后续流程失败也要走“回补”流程不能直接丢弃否则库存会莫名变少用户看到的余票数量越来越离谱。5.2 同一用户重复下多单与同座位票重复分配重复下单的处理方案是用户维度加分布式锁。比如用 Redis setnx 命令key为“order:lock:userId:{userId}”值为订单创建的任务ID设置过期时间为3秒。只有获取锁成功的请求可以继续其他请求直接返回“请勿重复提交”。如果分布式锁的实现只靠setnx而忘记设置过期时间一旦出现死锁或锁持有时间过长后续请求会被卡住很久这是新手最容易踩的坑。座位票重复分配的问题和库存超卖本质一样只是粒度从票档级细化到座位级。处理逻辑同样用Lua脚本保证座位状态变更的原子性或者把座位移到一个ZSet或Hash结构中用SPOP之类的命令原子地弹出未售座位。设计和说明时讲清楚这两者的递进关系往往会成为项目答辩或面试的加分项。5.3 缓存击穿 / 穿透 / 雪崩抢票系统最怕的是缓存集体失效导致数据库被打爆。击穿指某一个热点key失效的瞬间大量请求直击数据库雪崩指大量key同时过期导致数据库整体压力激增穿透指恶意请求查询不存在的keyRedis和数据库都查不到请求全部打到数据库。针对击穿我的做法是给热点key设置逻辑过期时间而不是物理过期后台用一个定时任务去刷新热点数据或者使用互斥锁——当某个key过期后只允许一个线程去数据库重建缓存其他线程等待缓存重建完成。针对穿透在网关服务或Web层加布隆过滤器对不存在的票档ID直接拦截。针对雪崩在设置过期时间时加一个随机扰动比如基础过期时间加上0到300秒的随机值避免大面积同时失效。6. 调试与部署经验补充6.1 本地联调环境搭建本地要跑通整套分布式系统我的建议是按依赖关系分步启动不要一上来把六个服务全启了。先启动Nacos和Redis再启动基础依赖的用户服务、演出服务、库存服务最后启动订单服务和网关服务。测量接口时用JMeter或Postman脚本模拟并发请求不要用浏览器手动点击并发量根本压不出来。联调期间打开Nacos控制面板的服务列表页观察每个服务的健康状态。如果一直有服务显示不健康八成是注册中心地址配置错误或服务心跳超时先检查server-addr配置再看服务所在机器的防火墙端口有没有放开。网关路由转发到下游服务失败时可以先用curl直接打下游服务的接口确认下游本身是否正常再排查网关路由的断言和过滤器位置问题。6.2 部署时最容易被忽略的配置项部署阶段最容易被忽略的是JVM参数和连接池参数。测试环境和生产环境的机器配置差距大我建议上线前用压测工具分别测出每个服务的建议线程池、数据库连接池和MQ的消费线程数。JVM堆内存根据服务大小设置为2G到4G年轻代比例保持默认即可不要乱调。在网关服务中要对超时时间做整体规划网关转发下游超时时间必须大于下游服务的响应时间否则用户端看到504错误而服务端其实还在处理。此外将日志级别设好生产环境至少保留INFO级别同时开启请求ID的链路透传这样一次请求在整个链路中的日志才能串联起来。没有链路透传排查问题只能靠猜效率极低。6.3 一套压测的最低配置参考我自己常用的压测配置如下用JMeter创建100个线程组每个线程循环20次模拟2000次请求观察网关服务的CPU、订单服务的响应时间和Redis的QPS。如果订单服务的平均响应时间超过2秒先看是否有慢SQL再看是否发生了消息队列积压。压测前给数据库执行一份大表索引检查确保订单表的order_no、库存流水表的biz_no都建了唯一索引。索引缺失会导致压测中途数据库CPU飙升这个坑我踩过不止一次。我还习惯压测后在订单表统计总订单数和支付成功数与Redis里的扣减记录做一次粗略对账。对不上就回到库存流水表逐步排查一般情况下问题都出在消息重复消费或库存回补的逻辑遗漏上。如果要把这个项目继续往深处做接下来的重点建议放在三块第一是订单超时自动关单的定时任务与支付回调链路的补偿机制第二是精确到座位选择的界面交互和座位锁定实现第三是压测报告的数据指标分析和调优节奏。这三块恰好是所有抢票系统后续真实上线时绕不开的硬骨头。以我自己的体会来看这类项目最有价值的地方不在于用了多少组件而在于每个组件都恰好解决了一个具体的并发痛点当你把组件和问题一一对应清楚时这套系统才真正算吃透了。