拓冰网站定制 
简介这份《机票预订系统详细设计说明书》面向软件工程课程设计、毕业设计及Java Web初学者聚焦于将概要设计落地为可编码的详细方案解决程序模块具体设计问题。文档以JavaJSP为技术栈采用AWT开发界面基于MyEclipse 7.0与MySQL数据库围绕查询预订系统与退订系统两大子模块展开。内容涵盖算法设计、数据结构设计、模块接口设计、数据库设计、界面设计与系统测试并逐项说明程序描述、功能、性能、输入输出项、流程逻辑、存储分配、注释设计、限制条件及测试计划还包含机票预订、取票通知、查询航班、打印机票、营运统计与后台航班管理等具体功能点。资源包为1个PDF文件大小约997KB结构完整、章节清晰便于按模块检索对照。目前已有1378人学习下载适合需要撰写详细设计文档、梳理数据库表结构与接口逻辑的读者参考借鉴。1. 机票预订系统详细设计说明书从一纸文档到可运行系统的落地拆解很多人拿到「机票预订系统详细设计说明书.pdf」这个标题第一反应是去找一份现成的模板把目录填满就交差。但真正做过机票预订系统的人都知道这份文档的价值不在于格式多漂亮而在于它能不能让后端、前端、测试三方在同一个认知框架下并行开工。机票预订系统不同于普通电商它的核心难点在于座位库存的并发扣减、航段与运价的组合逻辑、订单状态机的严格流转以及退改签带来的逆向流程。详细设计说明书要解决的就是把这些复杂度在编码之前拆解清楚让每个模块的输入输出、接口契约、异常分支都有据可查。这篇文章面向的是需要独立完成机票预订系统详细设计的工程师或者正在把一份设计文档落地成可运行代码的开发者。我会按「文档该写什么 → 每个模块怎么设计 → 落地时哪些地方容易翻车」的顺序把这份说明书从纸面推到可复现的工程实践。2. 详细设计说明书的骨架模块划分与接口契约怎么定2.1 从需求到模块机票预订系统的六个核心域机票预订系统的详细设计第一步不是画类图而是把业务边界切清楚。我一般会先把系统拆成六个核心域航班查询域、运价计算域、库存管理域、订单域、支付域、退改签域。每个域对应详细设计说明书里的一个独立章节章节内部再按「职责 → 对外接口 → 数据结构 → 异常处理」四段式展开。航班查询域负责接收用户输入的出发地、目的地、日期返回可用航班列表。它的核心接口是searchFlights(SearchRequest)输入参数包括departureCode、arrivalCode、departDate、passengerCount输出是ListFlightVO。这里有个容易忽略的点查询接口不应该直接查库存表而是查航班计划表加缓存因为库存是高频变动的查询时只需要展示「有票/无票」的粗粒度状态。运价计算域是机票系统区别于普通电商的关键。同一个航班不同舱位、不同提前天数、不同会员等级价格都不一样。详细设计说明书里必须把运价规则写成可配置的规则表而不是硬编码在代码里。常见做法是设计一张fare_rule表字段包括flight_no、cabin_class、advance_days_min、advance_days_max、base_price、discount_rate查询时按优先级匹配。库存管理域的核心是座位扣减。这里必须区分「物理库存」和「销售库存」。物理库存是飞机实际的座位数销售库存是允许超售的座位数。详细设计说明书里要明确扣减库存用数据库行锁还是 Redis 原子操作我的经验是查询阶段用 Redis 缓存下单阶段用数据库乐观锁加版本号支付超时后回补库存。订单域的状态机是详细设计说明书里最需要画清楚的部分。一个订单从创建到完成至少经历「待支付 → 已支付 → 已出票 → 已完成」异常分支还有「已取消」「已退款」「部分退票」。每个状态之间的流转条件、触发事件、超时策略都要在文档里用表格列出来。支付域和退改签域相对独立但接口契约必须和订单域对齐。支付回调的幂等性、退改签的费用计算规则都是详细设计说明书里必须写死的部分。2.2 接口契约的写法用表格替代大段文字详细设计说明书里最忌讳用大段文字描述接口。我习惯用表格把每个接口的入参、出参、异常码列清楚。以订单创建接口为例字段名类型必填说明flightNoString是航班号如 CA1234departDateString是出发日期格式 yyyy-MM-ddcabinClassString是舱位代码如 Y、C、FpassengerListArray是乘客列表最多 9 人contactPhoneString是联系人手机号idempotentKeyString是幂等键防止重复下单出参统一用ResultT包装包含code、message、data三个字段。异常码要分段管理1000 段是参数校验错误2000 段是库存不足3000 段是支付相关4000 段是退改签相关。这样前端拿到错误码就能直接定位问题类型。接口契约里还要写清楚超时时间和重试策略。比如库存扣减接口的超时时间建议设为 3 秒超过 3 秒未返回就视为失败触发回补逻辑。支付回调接口必须支持重试且每次重试都要用idempotentKey做幂等校验。2.3 数据库设计三张核心表撑起整个系统详细设计说明书里的数据库设计不需要把每张表都列出来但核心表必须写清楚字段、索引和约束。机票预订系统最核心的三张表是flight_inventory、order_main、order_passenger。flight_inventory表的关键字段包括id、flight_no、depart_date、cabin_class、total_seats、available_seats、version。其中version字段用于乐观锁每次扣减库存时UPDATE flight_inventory SET available_seats available_seats - 1, version version 1 WHERE id ? AND version ? AND available_seats 0。这条 SQL 的返回行数如果是 0说明库存不足或版本冲突需要重试或直接返回失败。order_main表的关键字段包括order_no、user_id、flight_no、depart_date、cabin_class、total_amount、order_status、pay_deadline、create_time。order_status用枚举值存储建议用数字而不是字符串比如 10 表示待支付20 表示已支付30 表示已出票40 表示已完成50 表示已取消。order_passenger表存储每个乘客的姓名、证件号、票号。这里要注意证件号的加密存储详细设计说明书里要写明加密算法和密钥管理方式。常见做法是用 AES 加密密钥存在配置中心不写在代码里。索引方面flight_inventory表要在(flight_no, depart_date, cabin_class)上建唯一索引order_main表要在(user_id, create_time)和(order_no)上建索引order_passenger表要在(order_no)上建索引。提示详细设计说明书里的数据库设计部分一定要写清楚每个字段的业务含义和取值范围不然后期开发容易把状态码写乱。3. 核心流程的详细设计从搜索到出票的每一步3.1 航班搜索与运价计算缓存策略和规则引擎航班搜索的详细设计核心是解决「查得快」和「查得准」的矛盾。用户输入出发地、目的地、日期后系统需要从航班计划表里筛选出符合条件的航班再关联运价规则算出每个舱位的价格。如果每次都查数据库响应时间很难控制在 200 毫秒以内。我一般会设计两级缓存第一级是本地缓存用 Caffeine 存最近 5 分钟的搜索结果第二级是 Redis 缓存存航班计划和运价规则过期时间设为 10 分钟。搜索请求进来后先查本地缓存命中直接返回未命中则查 RedisRedis 也没有再查数据库并回写缓存。运价计算用规则引擎的思路把规则存在数据库里启动时加载到内存。规则匹配的顺序是先按航班号匹配再按舱位匹配最后按提前天数匹配。如果多条规则同时命中取优先级最高的那条。详细设计说明书里要写清楚规则的优先级字段和冲突处理策略。# 运价规则匹配示例 def calculate_fare(flight_no, cabin_class, depart_date, base_price): advance_days (depart_date - date.today()).days rules load_rules_from_cache(flight_no, cabin_class) matched [] for rule in rules: if rule.advance_days_min advance_days rule.advance_days_max: matched.append(rule) if not matched: return base_price # 按优先级降序取第一条 matched.sort(keylambda r: r.priority, reverseTrue) best matched[0] return base_price * best.discount_rate这段代码的逻辑是先算出提前天数再从缓存里加载该航班该舱位的所有规则筛选出天数匹配的规则按优先级排序后取第一条用折扣率乘以基础价格得到最终运价。参数说明advance_days_min和advance_days_max是规则生效的天数区间discount_rate是折扣率priority是优先级数值越大越优先。这里有个容易翻车的地方如果规则表里存在重叠区间且优先级相同匹配结果就不确定。详细设计说明书里必须写明「同一航班同一舱位的规则区间不允许重叠优先级不允许重复」。3.2 库存扣减与订单创建乐观锁加幂等键库存扣减是机票预订系统里最容易出并发问题的地方。假设一个航班只剩 1 个座位两个用户同时下单如果不用锁两个订单都会创建成功但实际只有 1 个座位。详细设计说明书里必须把并发控制方案写清楚。我一般用「乐观锁 幂等键 预扣库存」的组合方案。用户点击下单后先调用预扣接口用乐观锁扣减available_seats扣减成功后再创建订单。如果扣减失败直接返回「库存不足」。订单创建时带上idempotentKey防止用户重复点击导致重复下单。-- 预扣库存的 SQL UPDATE flight_inventory SET available_seats available_seats - 1, version version 1 WHERE flight_no CA1234 AND depart_date 2025-06-01 AND cabin_class Y AND available_seats 0 AND version 5;这条 SQL 的执行逻辑是只有当available_seats 0且version等于当前版本号时才扣减库存并递增版本号。如果返回的影响行数为 0说明库存不足或版本冲突需要重新查询最新版本号后重试重试次数建议不超过 3 次。订单创建成功后要设置一个支付超时时间比如 15 分钟。超时未支付系统自动取消订单并回补库存。回补库存也要用乐观锁防止回补时把已经卖出的座位又加回去。# 订单创建与库存预扣的伪代码 def create_order(user_id, flight_no, depart_date, cabin_class, passengers, idempotent_key): # 幂等校验 existing get_order_by_idempotent_key(idempotent_key) if existing: return existing # 预扣库存 affected deduct_inventory(flight_no, depart_date, cabin_class) if affected 0: raise BusinessException(2001, 库存不足) # 创建订单 order Order(user_iduser_id, flight_noflight_no, ...) order.order_status 10 # 待支付 order.pay_deadline now() timedelta(minutes15) save_order(order) save_idempotent_key(idempotent_key, order.order_no) return order这段代码的关键点是幂等校验放在最前面库存预扣放在创建订单之前订单状态初始化为待支付支付超时时间设为 15 分钟。参数说明idempotent_key由前端生成建议用 UUIDdeduct_inventory返回影响行数0 表示扣减失败。3.3 支付回调与出票状态机流转和幂等处理支付回调是订单状态流转的触发点。详细设计说明书里要明确支付回调接口必须支持幂等同一个支付流水号多次回调只能处理一次。处理逻辑是先查订单状态如果已经是已支付或已出票直接返回成功如果是待支付则更新为已支付并触发异步出票流程。出票流程一般是调用航空公司的出票接口拿到票号后回写到order_passenger表同时把订单状态更新为已出票。如果出票失败订单状态回滚到已支付并记录失败原因等待人工介入或自动重试。# 支付回调处理 def handle_payment_callback(order_no, pay_serial_no, pay_amount): order get_order_by_no(order_no) if not order: raise BusinessException(3001, 订单不存在) if order.order_status 20: return SUCCESS # 已处理过直接返回 if pay_amount ! order.total_amount: raise BusinessException(3002, 支付金额不一致) # 更新订单状态 order.order_status 20 order.pay_serial_no pay_serial_no update_order(order) # 异步出票 send_ticket_async(order_no) return SUCCESS这段代码的逻辑是先查订单判断状态是否已经处理过再校验支付金额然后更新订单状态为已支付最后触发异步出票。参数说明pay_serial_no是支付平台的流水号用于对账send_ticket_async是异步方法不阻塞回调响应。注意支付回调接口一定要做金额校验防止篡改支付金额。同时要记录回调日志方便对账和排查。4. 避坑与排查详细设计说明书落地时的五个血泪教训4.1 库存扣减用了悲观锁导致接口大面积超时现象压测时库存扣减接口的响应时间从 50 毫秒飙升到 3 秒以上大量请求超时。原因开发同学在扣减库存时用了SELECT ... FOR UPDATE导致同一航班的库存行被锁住所有并发请求排队等待。解决改成乐观锁方案用version字段做版本控制扣减失败时重试而不是阻塞等待。重试次数控制在 3 次以内超过直接返回失败。4.2 订单状态机缺少「已取消」到「已退款」的流转现象用户取消已支付的订单后系统只把状态改成已取消但退款流程没有触发用户投诉。原因详细设计说明书里只画了正向流程漏掉了逆向流程的状态流转。解决在状态机里补上「已支付 → 已取消 → 已退款」的流转路径并明确退款触发条件。取消已支付订单时先调用退款接口退款成功后再更新状态为已退款。4.3 运价规则缓存没有设置过期时间导致价格更新不及时现象运营调整了某条航线的折扣率但用户看到的价格还是旧价格持续了半小时才更新。原因运价规则加载到本地缓存时没有设置过期时间导致缓存一直不刷新。解决本地缓存设置 5 分钟过期Redis 缓存设置 10 分钟过期。运营调整规则后通过消息队列发送刷新通知收到通知后主动清除本地缓存。4.4 支付回调没有做幂等导致重复出票现象支付平台因为网络抖动重试了回调系统处理了两次同一个订单出了两张票。原因支付回调接口没有校验订单状态每次回调都执行出票逻辑。解决在回调处理的最前面加状态判断如果订单状态已经是已支付或已出票直接返回成功。同时用pay_serial_no做唯一索引防止重复插入。4.5 数据库索引缺失订单查询慢到无法忍受现象用户查询历史订单时接口响应时间超过 5 秒数据库 CPU 飙升。原因order_main表只在order_no上建了索引用户按user_id查询时走了全表扫描。解决在(user_id, create_time)上建联合索引查询时按user_id过滤并按create_time排序。同时把历史订单归档到冷表减少热表数据量。5. 进阶技巧用状态机引擎和压测验证设计文档的完整性详细设计说明书写完不是终点能不能扛住真实流量才是。我一般会在文档评审通过后做两件事一是用状态机引擎把订单状态流转代码化二是用压测验证库存扣减的并发能力。状态机引擎我推荐用 Spring StateMachine 或者自己写一个轻量级的状态机。核心思路是把状态和事件定义成枚举把流转规则配置在数据库或 YAML 文件里。这样新增状态或调整流转规则时不需要改代码只需要改配置。比如states: - name: PENDING_PAYMENT code: 10 - name: PAID code: 20 - name: TICKETED code: 30 - name: COMPLETED code: 40 - name: CANCELLED code: 50 - name: REFUNDED code: 60 transitions: - from: PENDING_PAYMENT event: PAY_SUCCESS to: PAID - from: PAID event: TICKET_SUCCESS to: TICKETED - from: PAID event: CANCEL to: CANCELLED - from: CANCELLED event: REFUND_SUCCESS to: REFUNDED这份配置把订单的状态和流转规则完全外置代码里只需要调用stateMachine.sendEvent(orderNo, event)就能驱动状态流转。参数说明from是当前状态event是触发事件to是目标状态。每次流转前都要校验当前状态是否允许该事件不允许则抛出异常。压测方面我一般用 JMeter 或 wrk 模拟 500 个并发用户同时下单观察库存扣减的成功率和响应时间。重点看三个指标库存扣减的 TPS、订单创建的成功率、支付回调的幂等性。如果 TPS 低于 200 或者成功率低于 99%就需要检查数据库连接池、Redis 连接数和锁的粒度。还有一个容易被忽略的点详细设计说明书里要写明降级方案。比如 Redis 挂了怎么办我的做法是降级到数据库查询虽然慢但能保证可用。数据库主库挂了怎么办切换到从库但要从库延迟不能超过 1 秒。这些降级策略不需要写得太细但必须在文档里有记录不然线上出问题时临时想方案容易出乱子。最后说一个我自己的习惯详细设计说明书里的每个接口我都会在文档里附一个 curl 示例。这样前端和测试不用猜参数格式直接复制就能调。比如curl -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -d { flightNo: CA1234, departDate: 2025-06-01, cabinClass: Y, passengerList: [{name: 张三, idCard: 110101199001011234}], contactPhone: 13800138000, idempotentKey: 550e8400-e29b-41d4-a716-446655440000 }这个 curl 示例放在文档里比写十行参数说明都管用。我吃过亏文档里只写了字段名没写格式结果前端传的日期是2025/06/01后端解析失败排查了半天。从那以后每个接口我都附一个能直接跑的示例省得来回扯皮。希望帮到你。本文还有配套的精品资源点击获取 机票预订系统详细设计说明书：从文档到可运行系统的落地拆解
简介这份《机票预订系统详细设计说明书》面向软件工程课程设计、毕业设计及Java Web初学者聚焦于将概要设计落地为可编码的详细方案解决程序模块具体设计问题。文档以JavaJSP为技术栈采用AWT开发界面基于MyEclipse 7.0与MySQL数据库围绕查询预订系统与退订系统两大子模块展开。内容涵盖算法设计、数据结构设计、模块接口设计、数据库设计、界面设计与系统测试并逐项说明程序描述、功能、性能、输入输出项、流程逻辑、存储分配、注释设计、限制条件及测试计划还包含机票预订、取票通知、查询航班、打印机票、营运统计与后台航班管理等具体功能点。资源包为1个PDF文件大小约997KB结构完整、章节清晰便于按模块检索对照。目前已有1378人学习下载适合需要撰写详细设计文档、梳理数据库表结构与接口逻辑的读者参考借鉴。1. 机票预订系统详细设计说明书从一纸文档到可运行系统的落地拆解很多人拿到「机票预订系统详细设计说明书.pdf」这个标题第一反应是去找一份现成的模板把目录填满就交差。但真正做过机票预订系统的人都知道这份文档的价值不在于格式多漂亮而在于它能不能让后端、前端、测试三方在同一个认知框架下并行开工。机票预订系统不同于普通电商它的核心难点在于座位库存的并发扣减、航段与运价的组合逻辑、订单状态机的严格流转以及退改签带来的逆向流程。详细设计说明书要解决的就是把这些复杂度在编码之前拆解清楚让每个模块的输入输出、接口契约、异常分支都有据可查。这篇文章面向的是需要独立完成机票预订系统详细设计的工程师或者正在把一份设计文档落地成可运行代码的开发者。我会按「文档该写什么 → 每个模块怎么设计 → 落地时哪些地方容易翻车」的顺序把这份说明书从纸面推到可复现的工程实践。2. 详细设计说明书的骨架模块划分与接口契约怎么定2.1 从需求到模块机票预订系统的六个核心域机票预订系统的详细设计第一步不是画类图而是把业务边界切清楚。我一般会先把系统拆成六个核心域航班查询域、运价计算域、库存管理域、订单域、支付域、退改签域。每个域对应详细设计说明书里的一个独立章节章节内部再按「职责 → 对外接口 → 数据结构 → 异常处理」四段式展开。航班查询域负责接收用户输入的出发地、目的地、日期返回可用航班列表。它的核心接口是searchFlights(SearchRequest)输入参数包括departureCode、arrivalCode、departDate、passengerCount输出是ListFlightVO。这里有个容易忽略的点查询接口不应该直接查库存表而是查航班计划表加缓存因为库存是高频变动的查询时只需要展示「有票/无票」的粗粒度状态。运价计算域是机票系统区别于普通电商的关键。同一个航班不同舱位、不同提前天数、不同会员等级价格都不一样。详细设计说明书里必须把运价规则写成可配置的规则表而不是硬编码在代码里。常见做法是设计一张fare_rule表字段包括flight_no、cabin_class、advance_days_min、advance_days_max、base_price、discount_rate查询时按优先级匹配。库存管理域的核心是座位扣减。这里必须区分「物理库存」和「销售库存」。物理库存是飞机实际的座位数销售库存是允许超售的座位数。详细设计说明书里要明确扣减库存用数据库行锁还是 Redis 原子操作我的经验是查询阶段用 Redis 缓存下单阶段用数据库乐观锁加版本号支付超时后回补库存。订单域的状态机是详细设计说明书里最需要画清楚的部分。一个订单从创建到完成至少经历「待支付 → 已支付 → 已出票 → 已完成」异常分支还有「已取消」「已退款」「部分退票」。每个状态之间的流转条件、触发事件、超时策略都要在文档里用表格列出来。支付域和退改签域相对独立但接口契约必须和订单域对齐。支付回调的幂等性、退改签的费用计算规则都是详细设计说明书里必须写死的部分。2.2 接口契约的写法用表格替代大段文字详细设计说明书里最忌讳用大段文字描述接口。我习惯用表格把每个接口的入参、出参、异常码列清楚。以订单创建接口为例字段名类型必填说明flightNoString是航班号如 CA1234departDateString是出发日期格式 yyyy-MM-ddcabinClassString是舱位代码如 Y、C、FpassengerListArray是乘客列表最多 9 人contactPhoneString是联系人手机号idempotentKeyString是幂等键防止重复下单出参统一用ResultT包装包含code、message、data三个字段。异常码要分段管理1000 段是参数校验错误2000 段是库存不足3000 段是支付相关4000 段是退改签相关。这样前端拿到错误码就能直接定位问题类型。接口契约里还要写清楚超时时间和重试策略。比如库存扣减接口的超时时间建议设为 3 秒超过 3 秒未返回就视为失败触发回补逻辑。支付回调接口必须支持重试且每次重试都要用idempotentKey做幂等校验。2.3 数据库设计三张核心表撑起整个系统详细设计说明书里的数据库设计不需要把每张表都列出来但核心表必须写清楚字段、索引和约束。机票预订系统最核心的三张表是flight_inventory、order_main、order_passenger。flight_inventory表的关键字段包括id、flight_no、depart_date、cabin_class、total_seats、available_seats、version。其中version字段用于乐观锁每次扣减库存时UPDATE flight_inventory SET available_seats available_seats - 1, version version 1 WHERE id ? AND version ? AND available_seats 0。这条 SQL 的返回行数如果是 0说明库存不足或版本冲突需要重试或直接返回失败。order_main表的关键字段包括order_no、user_id、flight_no、depart_date、cabin_class、total_amount、order_status、pay_deadline、create_time。order_status用枚举值存储建议用数字而不是字符串比如 10 表示待支付20 表示已支付30 表示已出票40 表示已完成50 表示已取消。order_passenger表存储每个乘客的姓名、证件号、票号。这里要注意证件号的加密存储详细设计说明书里要写明加密算法和密钥管理方式。常见做法是用 AES 加密密钥存在配置中心不写在代码里。索引方面flight_inventory表要在(flight_no, depart_date, cabin_class)上建唯一索引order_main表要在(user_id, create_time)和(order_no)上建索引order_passenger表要在(order_no)上建索引。提示详细设计说明书里的数据库设计部分一定要写清楚每个字段的业务含义和取值范围不然后期开发容易把状态码写乱。3. 核心流程的详细设计从搜索到出票的每一步3.1 航班搜索与运价计算缓存策略和规则引擎航班搜索的详细设计核心是解决「查得快」和「查得准」的矛盾。用户输入出发地、目的地、日期后系统需要从航班计划表里筛选出符合条件的航班再关联运价规则算出每个舱位的价格。如果每次都查数据库响应时间很难控制在 200 毫秒以内。我一般会设计两级缓存第一级是本地缓存用 Caffeine 存最近 5 分钟的搜索结果第二级是 Redis 缓存存航班计划和运价规则过期时间设为 10 分钟。搜索请求进来后先查本地缓存命中直接返回未命中则查 RedisRedis 也没有再查数据库并回写缓存。运价计算用规则引擎的思路把规则存在数据库里启动时加载到内存。规则匹配的顺序是先按航班号匹配再按舱位匹配最后按提前天数匹配。如果多条规则同时命中取优先级最高的那条。详细设计说明书里要写清楚规则的优先级字段和冲突处理策略。# 运价规则匹配示例 def calculate_fare(flight_no, cabin_class, depart_date, base_price): advance_days (depart_date - date.today()).days rules load_rules_from_cache(flight_no, cabin_class) matched [] for rule in rules: if rule.advance_days_min advance_days rule.advance_days_max: matched.append(rule) if not matched: return base_price # 按优先级降序取第一条 matched.sort(keylambda r: r.priority, reverseTrue) best matched[0] return base_price * best.discount_rate这段代码的逻辑是先算出提前天数再从缓存里加载该航班该舱位的所有规则筛选出天数匹配的规则按优先级排序后取第一条用折扣率乘以基础价格得到最终运价。参数说明advance_days_min和advance_days_max是规则生效的天数区间discount_rate是折扣率priority是优先级数值越大越优先。这里有个容易翻车的地方如果规则表里存在重叠区间且优先级相同匹配结果就不确定。详细设计说明书里必须写明「同一航班同一舱位的规则区间不允许重叠优先级不允许重复」。3.2 库存扣减与订单创建乐观锁加幂等键库存扣减是机票预订系统里最容易出并发问题的地方。假设一个航班只剩 1 个座位两个用户同时下单如果不用锁两个订单都会创建成功但实际只有 1 个座位。详细设计说明书里必须把并发控制方案写清楚。我一般用「乐观锁 幂等键 预扣库存」的组合方案。用户点击下单后先调用预扣接口用乐观锁扣减available_seats扣减成功后再创建订单。如果扣减失败直接返回「库存不足」。订单创建时带上idempotentKey防止用户重复点击导致重复下单。-- 预扣库存的 SQL UPDATE flight_inventory SET available_seats available_seats - 1, version version 1 WHERE flight_no CA1234 AND depart_date 2025-06-01 AND cabin_class Y AND available_seats 0 AND version 5;这条 SQL 的执行逻辑是只有当available_seats 0且version等于当前版本号时才扣减库存并递增版本号。如果返回的影响行数为 0说明库存不足或版本冲突需要重新查询最新版本号后重试重试次数建议不超过 3 次。订单创建成功后要设置一个支付超时时间比如 15 分钟。超时未支付系统自动取消订单并回补库存。回补库存也要用乐观锁防止回补时把已经卖出的座位又加回去。# 订单创建与库存预扣的伪代码 def create_order(user_id, flight_no, depart_date, cabin_class, passengers, idempotent_key): # 幂等校验 existing get_order_by_idempotent_key(idempotent_key) if existing: return existing # 预扣库存 affected deduct_inventory(flight_no, depart_date, cabin_class) if affected 0: raise BusinessException(2001, 库存不足) # 创建订单 order Order(user_iduser_id, flight_noflight_no, ...) order.order_status 10 # 待支付 order.pay_deadline now() timedelta(minutes15) save_order(order) save_idempotent_key(idempotent_key, order.order_no) return order这段代码的关键点是幂等校验放在最前面库存预扣放在创建订单之前订单状态初始化为待支付支付超时时间设为 15 分钟。参数说明idempotent_key由前端生成建议用 UUIDdeduct_inventory返回影响行数0 表示扣减失败。3.3 支付回调与出票状态机流转和幂等处理支付回调是订单状态流转的触发点。详细设计说明书里要明确支付回调接口必须支持幂等同一个支付流水号多次回调只能处理一次。处理逻辑是先查订单状态如果已经是已支付或已出票直接返回成功如果是待支付则更新为已支付并触发异步出票流程。出票流程一般是调用航空公司的出票接口拿到票号后回写到order_passenger表同时把订单状态更新为已出票。如果出票失败订单状态回滚到已支付并记录失败原因等待人工介入或自动重试。# 支付回调处理 def handle_payment_callback(order_no, pay_serial_no, pay_amount): order get_order_by_no(order_no) if not order: raise BusinessException(3001, 订单不存在) if order.order_status 20: return SUCCESS # 已处理过直接返回 if pay_amount ! order.total_amount: raise BusinessException(3002, 支付金额不一致) # 更新订单状态 order.order_status 20 order.pay_serial_no pay_serial_no update_order(order) # 异步出票 send_ticket_async(order_no) return SUCCESS这段代码的逻辑是先查订单判断状态是否已经处理过再校验支付金额然后更新订单状态为已支付最后触发异步出票。参数说明pay_serial_no是支付平台的流水号用于对账send_ticket_async是异步方法不阻塞回调响应。注意支付回调接口一定要做金额校验防止篡改支付金额。同时要记录回调日志方便对账和排查。4. 避坑与排查详细设计说明书落地时的五个血泪教训4.1 库存扣减用了悲观锁导致接口大面积超时现象压测时库存扣减接口的响应时间从 50 毫秒飙升到 3 秒以上大量请求超时。原因开发同学在扣减库存时用了SELECT ... FOR UPDATE导致同一航班的库存行被锁住所有并发请求排队等待。解决改成乐观锁方案用version字段做版本控制扣减失败时重试而不是阻塞等待。重试次数控制在 3 次以内超过直接返回失败。4.2 订单状态机缺少「已取消」到「已退款」的流转现象用户取消已支付的订单后系统只把状态改成已取消但退款流程没有触发用户投诉。原因详细设计说明书里只画了正向流程漏掉了逆向流程的状态流转。解决在状态机里补上「已支付 → 已取消 → 已退款」的流转路径并明确退款触发条件。取消已支付订单时先调用退款接口退款成功后再更新状态为已退款。4.3 运价规则缓存没有设置过期时间导致价格更新不及时现象运营调整了某条航线的折扣率但用户看到的价格还是旧价格持续了半小时才更新。原因运价规则加载到本地缓存时没有设置过期时间导致缓存一直不刷新。解决本地缓存设置 5 分钟过期Redis 缓存设置 10 分钟过期。运营调整规则后通过消息队列发送刷新通知收到通知后主动清除本地缓存。4.4 支付回调没有做幂等导致重复出票现象支付平台因为网络抖动重试了回调系统处理了两次同一个订单出了两张票。原因支付回调接口没有校验订单状态每次回调都执行出票逻辑。解决在回调处理的最前面加状态判断如果订单状态已经是已支付或已出票直接返回成功。同时用pay_serial_no做唯一索引防止重复插入。4.5 数据库索引缺失订单查询慢到无法忍受现象用户查询历史订单时接口响应时间超过 5 秒数据库 CPU 飙升。原因order_main表只在order_no上建了索引用户按user_id查询时走了全表扫描。解决在(user_id, create_time)上建联合索引查询时按user_id过滤并按create_time排序。同时把历史订单归档到冷表减少热表数据量。5. 进阶技巧用状态机引擎和压测验证设计文档的完整性详细设计说明书写完不是终点能不能扛住真实流量才是。我一般会在文档评审通过后做两件事一是用状态机引擎把订单状态流转代码化二是用压测验证库存扣减的并发能力。状态机引擎我推荐用 Spring StateMachine 或者自己写一个轻量级的状态机。核心思路是把状态和事件定义成枚举把流转规则配置在数据库或 YAML 文件里。这样新增状态或调整流转规则时不需要改代码只需要改配置。比如states: - name: PENDING_PAYMENT code: 10 - name: PAID code: 20 - name: TICKETED code: 30 - name: COMPLETED code: 40 - name: CANCELLED code: 50 - name: REFUNDED code: 60 transitions: - from: PENDING_PAYMENT event: PAY_SUCCESS to: PAID - from: PAID event: TICKET_SUCCESS to: TICKETED - from: PAID event: CANCEL to: CANCELLED - from: CANCELLED event: REFUND_SUCCESS to: REFUNDED这份配置把订单的状态和流转规则完全外置代码里只需要调用stateMachine.sendEvent(orderNo, event)就能驱动状态流转。参数说明from是当前状态event是触发事件to是目标状态。每次流转前都要校验当前状态是否允许该事件不允许则抛出异常。压测方面我一般用 JMeter 或 wrk 模拟 500 个并发用户同时下单观察库存扣减的成功率和响应时间。重点看三个指标库存扣减的 TPS、订单创建的成功率、支付回调的幂等性。如果 TPS 低于 200 或者成功率低于 99%就需要检查数据库连接池、Redis 连接数和锁的粒度。还有一个容易被忽略的点详细设计说明书里要写明降级方案。比如 Redis 挂了怎么办我的做法是降级到数据库查询虽然慢但能保证可用。数据库主库挂了怎么办切换到从库但要从库延迟不能超过 1 秒。这些降级策略不需要写得太细但必须在文档里有记录不然线上出问题时临时想方案容易出乱子。最后说一个我自己的习惯详细设计说明书里的每个接口我都会在文档里附一个 curl 示例。这样前端和测试不用猜参数格式直接复制就能调。比如curl -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -d { flightNo: CA1234, departDate: 2025-06-01, cabinClass: Y, passengerList: [{name: 张三, idCard: 110101199001011234}], contactPhone: 13800138000, idempotentKey: 550e8400-e29b-41d4-a716-446655440000 }这个 curl 示例放在文档里比写十行参数说明都管用。我吃过亏文档里只写了字段名没写格式结果前端传的日期是2025/06/01后端解析失败排查了半天。从那以后每个接口我都附一个能直接跑的示例省得来回扯皮。希望帮到你。本文还有配套的精品资源点击获取