★ FEATURED ARTICLE 说出来有点丢人去年我帮女朋友抢某头部歌手的演唱会门票提前半小时守在电脑前三台手机加一台笔记本全开结果还是被卡在排队页面——4万人在线1万张票35秒售罄。那时候我就在想与其这样碰运气不如自己动手做一个基于Java和SpringCloud的分布式演唱会抢票系统把技术人的本事用在刀刃上。后来这个项目从架构设计到源码实现、调试文档、论文输出完整走了一遍也成了我做过的含金量最高的实战项目。这套系统解决的核心问题是高并发下的门票库存扣减、订单处理和一致性保障。如果你正打算做类似的毕设项目或者刚入行想找一个真实可落地的微服务练手项目又或者想弄明白抢票系统到底是怎么扛住千万级流量的那这篇文章值得你从头看到尾。我会把架构选型、模块拆分、秒杀式设计、压测踩坑、以及最后论文和调试文档怎么组织事无巨细讲一遍。1. 演唱会抢票系统难在哪先看清业务本质1.1 抢票不是买个票那么简单先说业务链路。演唱会票务系统表面上是“用户选个场次、选个票价、付款、收二维码”但它真正的复杂度藏在两个地方一是票是稀缺资源一场演唱会几万人抢几千张票二是流量呈脉冲式爆发开票那一瞬间所有并发请求同时打到系统上。核心流程拆开来看大概是这么几步用户浏览艺人主页、演唱会列表、场次信息进入某一场次的详情页查看座位分区、票价、剩余票数点击抢票提交预选座位或票价档位系统校验用户身份、校验是否已购票、锁定库存生成订单引导支付支付成功出票支付超时则订单取消、库存释放。每一个环节都有一个对应的技术难点。浏览环节是读多写少可以用缓存扛提交预选环节是前端高并发要限流锁库存环节是原子性和并发控制的角力一不留神就会超卖生成订单环节要防止重复下单支付超时环节要能及时释放库存。如果只是做一个“能跑”的Demo那确实不难一旦把并发量拉到真实抢票场景单机方案马上会暴露问题。用一个生活化的类比来说电影院选座是“细水长流”大家错峰买票数据库每一秒处理的请求量很平稳而演唱会抢票是一万个人同时去挤一扇门你不仅要知道门后面还有多少座位还得保证挤进门的每个人都有座位不能两个人挤进同一个位置。1.2 单体架构为什么在这个场景下扛不住可能有人会问我现在用SSM做一个单体应用把用户、订单、库存都放在一个工程里加上Redis缓存是不是也能抢票说实话几十个人同时访问是没有问题但真实抢票场景里这个方案会在三层溃败。第一层是Web容器。Tomcat默认线程池也就一两百个线程每个请求占用一个线程线程满了后面的请求只能排队。开票瞬间如果有数万个请求同时进来Tomcat线程池直接被打满新请求要么超时要么被拒绝。第二层是数据库。单体应用的所有表都在同一个MySQL实例上抢票的核心动作是扣库存也就是对同一行记录做update。数据库行锁让同一行在同一时刻只能被一个事务修改假设1万张票对应1万个库存记录但抢票的热点都集中在剩余票数这一个聚合字段上并发一上来数据库连接池先耗尽然后就是大量慢SQL堆积最终整个系统卡死。第三层是故障隔离。单体应用里任何一个模块出问题比如支付服务假死会导致整个抢票流程不可用这就是所谓的服务雪崩。更麻烦的是单体应用无法针对某个热点模块单独扩容——票务服务需要3台机器用户服务只需要1台但在单体架构里你只能把整个应用部署多份资源浪费严重。所以抢票系统的本质不是“把代码写出来”而是“把有限的计算资源用在刀刃上”。你需要一个能提前挡掉大量请求、能把任务异步化、能在局部出故障时保住整体的架构。这就是为什么要上分布式也正是这个项目标题里“分布式抢票系统”几个字的真正意义。2. 架构选型为什么是SpringCloudSSM这套组合2.1 SpringCloud解决了微服务的哪些麻烦事SpringCloud解决的是服务治理问题。你一旦把系统拆成用户服务、订单服务、票务服务、支付服务立刻会遇到几个非常现实的问题。第一个是服务发现与注册。服务之间互相调用不能写死IP和端口因为分布式环境下服务实例是动态伸缩的。今天票务服务有3个实例明天抢票高峰期可能要临时扩到10个调用方需要通过服务名去找可用实例这就是注册中心干的事。每个服务启动时把自己注册进去同时定时发送心跳服务下线时自动摘除。第二个是网关与路由。客户端只需要面对一个统一入口网关负责鉴权、限流、路由转发把请求分发到不同服务。比如“查询场次”的请求网关把它路由到票务服务登录的请求路由到用户服务提交订单的请求则需要在校验登录态后路由到订单服务。安全策略和流量控制集中在网关管理不会散落在各个服务里。第三个是熔断与降级。服务之间是链式调用的比如下单要调用票务服务扣库存再调用支付服务生成支付单。如果支付服务响应特别慢订单服务不能一直等着否则会把自己线程池里的线程全部耗尽。熔断机制可以做到下游服务慢到一定阈值后直接快速失败返回保护整个链路不被打垮。降级则是当非核心功能出问题时返回一个默认值或缓存值保证主流程还能走通。第四个是配置中心。不同环境的本机、测试服、生产环境的数据库地址、Redis地址、消息队列地址都不一样配置中心可以把这些配置集中管理、动态刷新改完配置不用重启服务。联调阶段这个功能非常省事改一个配置多个服务同时生效。我没有刻意追求复杂的微服务全家桶只挑了注册中心、网关、配置中心、熔断降级这几个核心组件。对于毕设或者中小型项目这一套足够再加复杂组件反而会把精力耗在运维上偏离了抢票系统本身。2.2 SSM在微服务里的精准定位SSM就是Spring SpringMVC MyBatis很多Java开发者最早接触的三件套。很多人觉得SSM是老技术和SpringCloud这种微服务框架不搭。其实恰恰相反SpringCloud本身构建在SpringBoot之上而SSM里的SpringMVC负责HTTP层、Spring负责Bean管理和事务、MyBatis负责数据库访问每个微服务内部仍然是标准的SSM分层结构。我举个例子订单服务对外提供“创建订单”的HTTP接口Controller用SpringMVC写接收参数并做基础校验Service层由Spring管理加上事务注解一个方法就是一个事务边界数据访问层用MyBatis的Mapper接口配合XML里的SQL操作订单表。这就是“微服务架构 服务内部SSM”的组合两条技术线各有分工并不冲突。为什么在SpringCloud项目里还要坚持用SSM而不是换成别的ORM框架我主要有三点考虑。第一MyBatis的SQL完全在手复杂查询和调优非常方便。抢票系统里有很多需要优化的SQL比如订单表必须要走索引、库存表更新要带条件手写SQL比自动生成的ORM语句更可控。第二学习曲线平缓接手项目的人维护成本低不需要额外引入代码生成器或复杂配置。第三对于答辩和面试来说SSM是考官最熟悉的组合你讲清楚“SpringCloud管服务治理、SSM管服务内部的实现”比堆一堆花哨框架更能体现你理解到位。说实话这套组合在真实企业里也大量存在很多业务系统就是SpringCloud做微服务治理服务内部用SpringMVC加MyBatis。它不是老古董而是一种务实的选择。2.3 技术栈清单与版本配合再把完整的技术栈清单列出来方便你建立整体概念。我不写死版本号因为不同时期SpringBoot和SpringCloud的版本兼容关系不一样你直接用当前稳定版或者学校实验环境指定的版本都行。关键要记住SpringCloud和SpringBoot有严格的版本对应关系必须查官方Release Notes版本错配会出现各种莫名其妙的启动报错。开发语言Java 8或11微服务框架SpringCloud含注册中心、网关、熔断、配置中心Web层与数据层SpringMVC MyBatis数据库MySQL 5.7或8.0InnoDB引擎缓存与分布式锁Redis消息队列RabbitMQ毕设环境更轻量业务上也能说清楚反向代理与负载入口Nginx构建与版本管理Maven Git这套组合的合理性在于每个组件都是经过大量生产验证的成熟方案资料多、问题排查有迹可循而且普通笔记本就能跑起来。我不建议在抢票系统里引入太重的容器编排平台那样项目会变成运维部署的演示偏离了“高并发抢票”这个核心主题。3. 系统拆成哪几个服务模块划分与数据库设计3.1 服务模块划分单机应用拆开的边界分布式系统最核心的问题是拆分粒度。拆太小服务数量庞杂联调和运维成本高拆太大又回到单体应用的老路。我最后拆成了五个业务服务加一个网关。用户服务负责注册、登录、Token鉴权、用户信息管理。抢票前需要校验用户身份下单后需要记录购票用户独立成服务后既可以被其他服务复用登录态又不会因为其他模块重启而影响认证功能。票务服务负责艺人信息、演唱会场次、座位分区、票价、库存查询和维护。这是抢票系统里最重要的读服务演唱会详情页的所有数据都从这里出。同时它也是库存扣减的核心服务所有抢票动作最终都要经过它操作Redis中的库存。订单服务负责订单的创建、查询、取消和超时关单。订单状态流转是一个独立领域和票务服务解耦以后票务服务不需要关心订单是怎么被处理、怎么超时的只需要知道库存有没有被扣掉。支付服务负责对接第三方支付渠道生成支付单、处理支付回调、处理退款和对账。我在设计里保留了一个适配层方便以后切换不同的支付渠道这也是扩展性的一种体现。通知服务负责发送短信、站内信和邮件比如抢票成功提醒、订单超时提醒、演唱会开演提醒。它从消息队列里消费通知事件慢慢地处理完全不占用核心抢票链路。网关服务统一接收前端请求做限流、鉴权、路由分发。它不是业务服务却是所有流量的第一道关卡。服务调用关系可以用一条主线概括Nginx先挡一层网关再收一道请求按路径路由到票务服务或订单服务服务之间通过消息队列异步解耦。当时设计时我坚持一个原则抢票瞬间的核心链路要尽量短非核心的、可以稍后完成的事情全部异步化。这个原则帮我避免了很多性能问题。3.2 数据库核心表设计数据库设计是整个项目的底座。我按领域把不同业务的表拆到不同服务的数据库但联调初期为了降低环境复杂性会先让它们都在同一个MySQL实例里用不同的数据库名做逻辑隔离。用户表是最基础的表字段主要有主键、用户名、密码密文、手机号、注册时间、状态。抢票相关的实名认证信息我也会放在用户表里因为演出门票实名制是硬需求。艺人表、演唱会表、场次表这三张表是递进关系。艺人表存姓名、封面图、简介演唱会表存演唱会名称、艺人ID、城市、场馆、演出时间、状态场次表存演唱会ID、场次时间、场馆座位容量、销售状态。票档与库存表是核心。字段包括票档ID、场次ID、票档名称内场前区、看台A区等、票价、总库存、剩余库存、版本号。注意这里的“剩余库存”在数据库里只是兜底数据大量实时扣减发生在Redis中。数据库里的剩余库存用于最终一致性和对账防止Redis数据丢失后完全不可恢复。订单表包含订单号、用户ID、场次ID、票档ID、数量、总金额、状态待支付、已支付、已取消、已出票、创建时间、支付时间、超时时间。订单号必须是全局唯一的我用的是“时间戳 用户ID 随机数”的方式生成。订单表要加两个关键索引一个是用户ID和场次ID的组合唯一索引防止同一用户在同一场次重复下单另一个是订单状态和超时时间的组合索引供定时任务扫描超时订单使用。支付流水表记录每一笔支付请求包含流水号、订单号、支付渠道、支付金额、支付状态、回调时间、回调原始报文。这张表是财务对账的基础也是分布式事务里“本地消息表”模式的重要组成部分。座位表是可选的如果演唱会支持选座需要单独维护不支持选座而是按票档销售则可以省略。我当时选择的方案是票价档位模式这样库存扣减的并发控制会简单很多我更推荐在毕设里采用这种模式。3.3 分库分表现在需要吗很多同学一上来就问要不要分库分表。我的建议是毕设项目可以不搞但你要能说清楚“什么情况下才需要”。思考一下抢票系统真正的热点不在于订单表的数据总量而在于同一时刻的并发写入。1万张票抢完订单表只多了1万行对MySQL来说毫无压力。真正的瓶颈是那一两秒内对同一个库存聚合行的并发update这个可以用Redis挡掉而不是靠分库分表。那什么情况下才需要分库分表当订单总量达到千万级别、单表查询明显变慢、且业务上能找到一个稳定的分片键时再考虑。比如按用户ID哈希分到多个库。我虽然没有做分库分表但在设计文档里专门写了一段“预留分库分表扩展点”比如订单表预留了用户ID分片键字段将来可以平滑迁移。这样写反而显得你有全局视野答辩时也比较加分。4. 抢票瞬间的设计核心库存扣减、限流与削峰4.1 第一道防线把请求挡在外面高并发处理的第一原则是能挡就挡别放进来。抢票系统里绝大部分请求其实不需要进入后端服务挡得越早后面的压力越小。前端层面抢票按钮在开票前提前置灰只有到开票时间才激活客户端自己限制点击频率一个用户一秒之内只能发一次抢票请求。还可以加滑块验证码或者行为校验拦截一部分自动化脚本。网关层面我对“创建订单”这种关键接口做限流每个用户每秒最多3次请求每个IP每秒最多10次。限流算法用的是令牌桶允许一定量的突发流量超出的请求直接返回“排队人数过多请稍后再试”的提示。令牌桶的核心思想是系统以固定速率生成令牌请求来了要拿走一个令牌才能继续处理令牌不够就直接拒绝。Nginx层面在网关前面再加一层反向代理同时可以配置并发连接数限制。静态资源和动态接口分开部署图片、CSS、JS这些静态内容走内容分发网络不要挤占后端的带宽和连接。这一整套流程下来假设原始有10万个抢票请求到达网关的可能只有1万个能通过网关继续往后走的就更少了。数据库永远不需要面对十万并发这就是“削峰”的第一步。4.2 库存扣减从数据库行锁换成Redis原子操作库存扣减是整个抢票系统里最关键的代码没有之一。最容易犯的错误是“先查再扣”int stock getStock(ticketId); if (stock 0) { updateStock(ticketId, stock - 1); }这段代码在并发下一定会超卖。原因很简单两个线程同时查到库存等于1都判定可以买然后都执行扣减库存就变成了-1。解决办法之一是把判断和扣减合并成一条SQLUPDATE stock_table SET remaining remaining - 1 WHERE ticket_id ? AND remaining 0;这样数据库层面能保证同一个时刻只有一个事务能扣成功。但之前说过热点集中在这一行的并发update上数据库行锁在高并发下还是扛不住所以我把实时扣减放到了Redis。Redis扣减的核心是用Lua脚本保证原子性。Lua脚本在Redis里是原子执行的执行过程中不会被其他命令打断所以并发扣减不会出错-- KEYS[1] 是票档在Redis里的库存Key -- ARGV[1] 是本次购买数量 local stock tonumber(redis.call(get, KEYS[1])) if not stock or stock tonumber(ARGV[1]) then return 0 end redis.call(decrby, KEYS[1], tonumber(ARGV[1])) return 1这段脚本先读取当前库存如果库存不足直接返回0表示抢票失败如果库存充足一次性扣减指定数量。由于整个脚本是原子的即使同一时刻有几千个请求在扣同一个Key也只会让库存从5000变成4999再变成4998不可能变成负数。扣减成功之后订单数据不会直接写数据库而是发送到消息队列等消费者慢慢落库。完整流程是请求到票务服务扣Redis库存扣减成功则生成一条预下单消息发到MQ扣减失败则直接返回“票已抢完”。这样订单服务不会在抢票瞬间被打爆。当然Redis也可能宕机Redis里的库存有丢失风险。所以Redis库存只是临时凭证数据库里还需要一份真实的库存记录。消费者在落库时对数据库库存再做一次校验扣减成功后订单状态才能变成“待支付”。如果发现数据库库存不足要触发告警并对账把Redis库存修正回来。这个“缓存加数据库双校验”的思路在答辩时非常加分。4.3 防止重复下单幂等与分布式锁抢票场景里用户会疯狂点击按钮即使前端做了防重网络重试、脚本刷票也可能导致同一个用户在几十毫秒内发出多个抢票请求。如果不去重用户会生成多张重复订单。我在订单服务里做了两道保障。第一道是数据库唯一索引。在预下单阶段先插入一条幂等记录用“用户ID 场次ID”做唯一键第二个请求插入时必然因为唯一键冲突失败业务代码捕获冲突后返回“您已提交过订单请不要重复操作”。这道保障是最终兜底无论前面出了什么漏子数据库约束会把重复数据挡在门外。第二道是分布式锁。抢票涉及到多个服务节点同时处理同一个用户的请求普通JVM锁在分布式环境下完全无效必须用分布式锁。我用的实现是基于Redis的分布式锁客户端以“用户ID 场次ID”作为锁的Key抢到锁的请求才允许进入下单流程拿不到锁的直接返回“正在处理中”。锁的超时时间设置非常讲究太短处理还没结束锁就释放了第二个请求又挤进来太长用户下一次抢票要等很久。经验值是“下单处理链路的最大耗时再乘以1.5到2倍”这个值需要通过压测来确定。4.4 消息队列削峰填谷与超时关单消息队列在抢票系统里承担了三个职责都很重要。第一个职责是削峰填谷。抢票瞬间有大量订单消息进来数据库写入能力是有限的直接把消息全部灌进数据库会导致连接池耗尽。有了MQ订单服务作为消费者就能按自己的消费速度拉取消息高峰期处理不过来就暂时在队列里堆积低峰期继续消费。对用户来说支付前的体验几乎没有差别对系统来说数据库被保护住了。第二个职责是业务解耦。票务服务扣完库存后发一个“库存已扣减”事件订单服务订阅这个事件去创建订单通知服务订阅它去发提醒支付服务订阅它去生成支付单。每新增一个关心该事件的模块不需要改动票务服务的代码只要新模块自己去订阅队列就行。第三个职责是延迟队列实现超时关单。演唱会抢票通常要求用户在5分钟内完成支付超时自动取消订单并释放库存。实现方式是订单创建后发送一条延迟5分钟的消息到延迟队列时间一到消费者收到消息检查订单状态——如果还是“待支付”就关闭订单、调用票务服务回补库存如果已经支付就不做任何处理。回补库存的思路很简单把Redis库存加回去再更新数据库剩余库存同时记录一条回补日志。4.5 分布式事务的取舍最终一致性分布式系统里没有所谓的强事务银弹抢票场景更是如此。我采用的是“本地消息表 MQ”的最终一致性模式。以扣库存和创建订单为例票务服务在本地数据库里写入一条“库存扣减记录”并在同一个事务里把一条“待发送消息”插入本地消息表随后提交事务。接着有一个定时任务扫描消息表把状态为“待发送”的消息投递到MQ。订单服务消费消息、创建订单成功后回调票务服务标记消息为“已处理”。整个过程不要求“扣库存”和“创建订单”这两个动作原子完成允许中间存在一两秒的不一致窗口期但最终两边数据会保持一致。订单服务消费时的幂等性靠“订单号”这个业务键保证重复消息不会重复创建订单。为什么不用分布式事务框架做强一致一是引入成本高二是不符合业务节奏。从点击抢票到支付有5分钟时间中间状态暂时不一致用户完全感知不到。我甚至在答辩时主动说“我没有选择强事务而是用最终一致性换取高并发下的性能与可用性”这个取舍本身就是加分项。5. 调试与压测实录那些文档里不会写的坑5.1 本地联调的三个经典问题第一个问题是注册中心地址配置错误。各个服务启动时要连接注册中心如果注册中心没启动或者地址写错服务根本不会上线。我建议把注册中心作为环境里第一个启动的组件并且用独立的主类先启动它再启动其他服务。第二个问题是端口冲突。一个服务一个端口本地跑多个服务经常遇到8080、8081被占用的问题。解决办法是在启动参数里指定server.port或者统一在配置文件中设置。我习惯给用户服务、票务服务、订单服务、支付服务、通知服务分别分配不同的端口并在调试文档里列清楚。第三个问题是跨服务调用时序列化规则不一致。服务之间通过HTTP加JSON通信如果时间格式、字段命名不统一很容易出现数据解析失败。我建议定义一份公共的DTO模块把所有服务间传输的对象统一放在里面用Maven多模块管理。这样能省掉大量重复代码也不会出现字段对不上的低级错误。5.2 压测暴露的问题连接池和线程池我用压测工具模拟了2000个并发用户同时抢票第一轮压测结果惨不忍睹。Redis连接被拒绝、数据库连接池爆掉、Tomcat线程堆积、接口响应时间从几十毫秒涨到十秒以上。逐项排查后发现是三个基础参数没有调好。第一个是Tomcat线程池。默认的核心线程数和最大线程数偏小高并发下请求只能排队等待。我调大了线程池的最大线程数并设置了合理的队列容量让线程池在突发流量下能排队而不是直接拒绝。第二个是Redis连接池。每个服务实例默认创建的Redis连接数有限压测时瞬间被拿完。我把最大连接数调高同时设置了合理的连接超时和读取超时避免线程无限期等待。第三个是数据库连接池。默认最大池大小只有102000并发一来连接全部被占。我把最大池大小调高并把连接超时设为一个合理的上限。这里有一个很重要的经验数据库连接池不是越大越好连接太多反而会拖慢数据库CPU需要通过压测找一个平衡点。在我的项目里50个连接是足够的。压测完之后我还会盯三个指标接口的TP99响应时间、服务器的CPU使用率、以及JVM的GC频率。有一次压测时大量对象频繁创建导致GC吞吐量下降排查后发现是抢票接口里每次请求都创建了一些不必要的对象优化之后JVM明显稳定了。5.3 超卖问题从复现到修复第一版压测时我故意把Redis库存初始化为100用500个并发用户去抢最后发现数据库里的订单量达到103张。库存明显超卖。复现步骤其实很简单先确认Redis库存还有剩余再观察数据库订单数超过初始库存。根因是“扣Redis库存”和“更新数据库库存”被拆成了两步两个操作之间存在时间差。消费者在同步数据库时没有做最终数量校验导致数据库里的剩余库存被扣成了负数。修复方案分三层。第一层扣减Redis库存的Lua脚本里加了“不大于总库存”的判断从源头拦截不合法扣减。第二层消费者在创建订单前对数据库执行一条带“剩余库存大于0”条件的更新SQL确保数据库真实库存不会被扣成负数。第三层加了一个定时对账任务每隔一段时间比对Redis库存、数据库库存和实际订单数量发现不一致就报警。三层都做好以后我再压测订单数量和初始库存严格一致不再出现超卖。5.4 支付回调和幂等的边界条件还有一个容易被忽略的边界用户在支付页停留很久之后又点了一次“支付”结果支付回调被第三方渠道发送了两次。如果幂等没做好用户会被扣两次款。我在支付服务里用“支付流水号”做唯一约束回调处理之前先尝试插入流水记录重复回调会因为主键冲突被拒掉。这个排查经历让我明白一个原则分布式系统里凡是涉及“钱”和“票”的操作幂等设计是一票否决项没有商量余地。6. 论文、调试文档和讲解把项目做成完整的交付物6.1 论文怎么写得有血有肉这个项目如果只是把代码写出来那只能算完成了一半另一半是把整个过程整理成文档。论文我按标准结构来写摘要、绪论、需求分析、概要设计、详细设计、系统实现、系统测试、总结与展望。需求分析章节我把用户角色分成普通用户和管理员两类。普通用户需要的功能是注册登录、浏览演唱会、抢票、支付、查看订单管理员需要的是艺人管理、演唱会管理、场次管理、订单查询、数据统计。每个功能都用用例图表达并配一段文字说明业务规则比如“同一用户同一场次只能下一单”“订单超过5分钟未支付自动取消”。这些规则是后续设计和测试的依据必须写清楚。详细设计章节我放了三张图系统架构图、核心时序图、数据库ER图。架构图展示网关、各服务、中间件的部署关系时序图完整展示用户抢票的调用链包括Nginx、网关、票务服务、Redis、MQ、订单服务、支付服务之间的消息流转ER图展示各表之间的外键关系。三张图是论文专业度的重要体现也几乎是答辩时必被问到的地方。测试章节不要只写“系统运行正常”。我建议列一张功能测试用例表每条包含用例编号、操作步骤、预期结果、实际结果。性能测试单独开一节把压测工具、并发数、TPS、响应时间、数据库连接池状况写清楚。比如“在2000并发下抢票接口TP99为800毫秒库存无超卖”。这组实测数据在答辩时非常有说服力。6.2 调试文档怎么写调试文档的核心目标是让另一个人拿到项目后不需要问你就能顺利跑起来。我按三个部分来组织。环境准备部分写清JDK安装配置、Maven配置、MySQL初始化脚本执行、Redis启动、MQ安装启动、Nginx配置。每一步都要写清验证方式比如“启动后浏览器访问某个端口能看到控制台提示说明环境OK”。这部分要写成傻瓜式教程不要默认对方什么都会。启动顺序部分先启动配置中心、注册中心再启动网关最后启动各业务服务。每个服务启动后观察哪些日志、验证哪些接口都列出来。我见过太多人把服务乱序启动结果调用方找不到服务。文档里写清楚顺序能省掉大量答疑时间。常见问题排查部分把开发中真实踩过的坑都放进去比如端口被占用怎么办、数据库连接失败怎么检查、Redis连接不上怎么定位、MQ消息积压怎么排查。每一类问题配上排查步骤和关键词让我在后期演示时遇到问题能立刻回忆起来。这份文档的实际价值不亚于代码。6.3 讲解演示与答辩准备最后说说讲解。拿到项目以后无论是面试还是答辩你都要在有限时间内把“做了什么、为什么这么做、效果怎么样”讲清楚而不是对着PPT念功能列表。我的建议是讲一条主线从用户点击抢票按钮到订单生成的完整链路把限流、缓存扣减、消息削峰、最终一致性这几个关键点串起来。每个关键点配一个小故事。比如“第一次压测超卖了30张票我通过把扣库存改成Redis Lua脚本、把落库改成消息异步最终解决了超卖”。故事永远比抽象概念好记也更能展示你的思考过程。演示环节一定要准备兜底方案。抢票流程依赖Redis和MQ如果现场没有完整环境至少要准备一份录好的演示视频。我自己吃过亏模拟答辩时现场网络波动Redis连接超时页面直接报错。从那以后我养成了习惯所有关键流程都提前录屏并把录屏文件一起放进交付资料。做完整套系统我最大的体会是抢票系统的技术难点不在于某一项技术本身而在于把多项技术组合起来保护同一条业务链路。限流挡流量、缓存扛热点、队列削峰、异步解耦、分布式锁防并发、最终一致性兜底每一步都在和“极端情况”博弈。如果你准备自己做这个项目我的建议是先跑通单体版本再逐步引入分布式组件每引入一个就压测一次记录前后对比数据。这样你拿到的不仅是一份完整的源码和文档还能在答辩或面试时讲出最有说服力的数字和故事。这个项目后续可扩展的方向还挺多比如候补抢票、多场次组合预约、电子票进场核销、防黄牛风控策略、座位级别的可视化选座。我当时只做到了前两个剩下的就看你自己继续往下填坑了。
阅读完成 · 觉得有帮助？
