企业官网建设流程全解析

说出来有点丢人，去年我帮女朋友抢某头部歌手的演唱会门票，提前半小时守在电脑前，三台手机加一台笔记本全开，结果还是被卡在排队页面——4万人在线，1万张票，35秒售罄。那时候我就在想，与其这样碰运气，不如自己动手做一个基于Java和SpringCloud的分布式演唱会抢票系统，把技术人的本事用在刀刃上。后来这个项目从架构设计到源码实现、调试文档、论文输出，完整走了一遍，也成了我做过的含金量最高的实战项目。

这套系统解决的核心问题是高并发下的门票库存扣减、订单处理和一致性保障。如果你正打算做类似的毕设项目，或者刚入行想找一个真实可落地的微服务练手项目，又或者想弄明白抢票系统到底是怎么扛住千万级流量的，那这篇文章值得你从头看到尾。我会把架构选型、模块拆分、秒杀式设计、压测踩坑、以及最后论文和调试文档怎么组织，事无巨细讲一遍。

1. 演唱会抢票系统难在哪：先看清业务本质

1.1 抢票不是买个票那么简单

先说业务链路。演唱会票务系统表面上是“用户选个场次、选个票价、付款、收二维码”，但它真正的复杂度藏在两个地方：一是票是稀缺资源，一场演唱会几万人抢几千张票；二是流量呈脉冲式爆发，开票那一瞬间所有并发请求同时打到系统上。

核心流程拆开来看，大概是这么几步：用户浏览艺人主页、演唱会列表、场次信息；进入某一场次的详情页，查看座位分区、票价、剩余票数；点击抢票，提交预选座位或票价档位；系统校验用户身份、校验是否已购票、锁定库存；生成订单，引导支付；支付成功出票，支付超时则订单取消、库存释放。

每一个环节都有一个对应的技术难点。浏览环节是读多写少，可以用缓存扛；提交预选环节是前端高并发，要限流；锁库存环节是原子性和并发控制的角力，一不留神就会超卖；生成订单环节要防止重复下单；支付超时环节要能及时释放库存。如果只是做一个“能跑”的Demo，那确实不难，一旦把并发量拉到真实抢票场景，单机方案马上会暴露问题。

用一个生活化的类比来说：电影院选座是“细水长流”，大家错峰买票，数据库每一秒处理的请求量很平稳；而演唱会抢票是一万个人同时去挤一扇门，你不仅要知道门后面还有多少座位，还得保证挤进门的每个人都有座位，不能两个人挤进同一个位置。

1.2 单体架构为什么在这个场景下扛不住

可能有人会问：我现在用SSM做一个单体应用，把用户、订单、库存都放在一个工程里，加上Redis缓存，是不是也能抢票？说实话，几十个人同时访问是没有问题，但真实抢票场景里，这个方案会在三层溃败。

第一层是Web容器。Tomcat默认线程池也就一两百个线程，每个请求占用一个线程，线程满了后面的请求只能排队。开票瞬间如果有数万个请求同时进来，Tomcat线程池直接被打满，新请求要么超时，要么被拒绝。

第二层是数据库。单体应用的所有表都在同一个MySQL实例上，抢票的核心动作是扣库存，也就是对同一行记录做update。数据库行锁让同一行在同一时刻只能被一个事务修改，假设1万张票对应1万个库存记录，但抢票的热点都集中在剩余票数这一个聚合字段上，并发一上来，数据库连接池先耗尽，然后就是大量慢SQL堆积，最终整个系统卡死。

第三层是故障隔离。单体应用里任何一个模块出问题，比如支付服务假死，会导致整个抢票流程不可用，这就是所谓的服务雪崩。更麻烦的是，单体应用无法针对某个热点模块单独扩容——票务服务需要3台机器，用户服务只需要1台，但在单体架构里你只能把整个应用部署多份，资源浪费严重。

所以抢票系统的本质不是“把代码写出来”，而是“把有限的计算资源用在刀刃上”。你需要一个能提前挡掉大量请求、能把任务异步化、能在局部出故障时保住整体的架构。这就是为什么要上分布式，也正是这个项目标题里“分布式抢票系统”几个字的真正意义。

2. 架构选型：为什么是SpringCloud+SSM这套组合

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.0，InnoDB引擎
• 缓存与分布式锁：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。解决办法之一是把判断和扣减合并成一条SQL：

UPDATE 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连接数有限，压测时瞬间被拿完。我把最大连接数调高，同时设置了合理的连接超时和读取超时，避免线程无限期等待。

第三个是数据库连接池。默认最大池大小只有10，2000并发一来，连接全部被占。我把最大池大小调高，并把连接超时设为一个合理的上限。这里有一个很重要的经验：数据库连接池不是越大越好，连接太多反而会拖慢数据库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连接超时，页面直接报错。从那以后我养成了习惯，所有关键流程都提前录屏，并把录屏文件一起放进交付资料。

做完整套系统，我最大的体会是：抢票系统的技术难点不在于某一项技术本身，而在于把多项技术组合起来保护同一条业务链路。限流挡流量、缓存扛热点、队列削峰、异步解耦、分布式锁防并发、最终一致性兜底，每一步都在和“极端情况”博弈。如果你准备自己做这个项目，我的建议是先跑通单体版本，再逐步引入分布式组件，每引入一个就压测一次，记录前后对比数据。这样你拿到的不仅是一份完整的源码和文档，还能在答辩或面试时讲出最有说服力的数字和故事。

这个项目后续可扩展的方向还挺多，比如候补抢票、多场次组合预约、电子票进场核销、防黄牛风控策略、座位级别的可视化选座。我当时只做到了前两个，剩下的就看你自己继续往下填坑了。