当前位置: 首页 > news >正文

订单模块逐字稿

订单表设计

订单表通常采用的结构是订单主表与订单明细表一对多关系结构,比如:在电商系统中,一个订单购买的多件不同的商品,设计订单表和订单明细表:
订单表:记录订单号、订单金额、下单人信息、订单状态等信息。
订单明细表:记录该订单购买商品的信息,包括:商品名称、商品价格、交易价格、购买商品数量等。
如果系统需求是一个订单只包括一种商品,此时无须记录订单明细,将购买商品的详细信息记录在订单表即可,设计字段包括:订单号、订单金额、下单人、订单状态、商品名称、购买商品数量等。
本项目订单表包括以下内容:
订单基础信息:订单号、订单状态、排序字段、是否显示标记等。
价格信息:单价、购买数量、优惠金额、订单总金额等。
下单人信息:下单人ID、联系方式、位置信息(相当于收货地址)等。
服务信息(如果有订单明细表要放在订单明细表):服务类型名称、服务项名称、服务单价、价格单位、购买数量等。

核心流程

1.订单创建阶段

用户发起下单请求后,系统进入订单创建流程:
用户通过前端提交订单请求到 orders-manager 模块
系统调用 IOrdersCreateService 服务处理订单创建逻辑
生成订单记录,保存到 Orders 表中,订单初始状态设置为"待支付"(0)
系统会锁定相关资源,如优惠券、服务时间等,防止资源冲突
创建订单快照信息用于后续状态变更处理

2.订单支付阶段

用户完成支付操作后:
支付系统回调通知支付成功
系统触发 OrderPayedHandler 处理器处理支付成功事件
订单状态从"待支付"(0)通过状态机变更为"派单中"(100)
系统将订单信息同步到 OrdersDispatch 表,使订单进入派单池等待分配
如果用户在规定时间内未支付,系统通过 OrdersHandler.cancelOverTimePayOrder 定时任务自动取消订单
取消时会记录取消信息到 OrdersCanceled 表,并更新订单状态为"已取消"(600)

3.派单阶段

订单进入派单流程:
系统根据配置的派单策略(抢单或派单)将订单分配给合适的服务人员
派单逻辑在 jzo2o-orders-dispatch 模块中处理,包含多种分配策略如 LeastAcceptOrderStrategyImpl、EvaluationScoreStrategyImpl 等
派单成功后,订单状态通过状态机从"派单中"(100)变更为"待服务"(200)
订单从 OrdersDispatch 表移除,同时创建 OrdersServe 服务任务记录,表示服务任务已生成
如果是抢单模式,订单会先放入 OrdersSeize 抢单池中

4.服务执行阶段

服务人员开始提供服务:
服务人员确认接单后,订单状态保持"待服务"(200)
服务人员点击"开始服务"按钮,系统触发 OrderStartServeHandler 处理器
订单状态通过状态机从"待服务"(200)变更为"服务中"(300)
系统记录实际服务开始时间 realServeStartTime
服务完成后,服务人员点击"完成服务"按钮,触发 OrderCompleteServeHandler 处理器
订单状态从"服务中"(300)变更为"待评价"(400)
系统记录实际服务结束时间 realServeEndTime

5.评价阶段

用户对已完成的服务进行评价:
用户在前端界面提交服务评价信息
系统触发 OrderEvaluateHandler 处理器处理评价事件
订单状态从"待评价"(400)通过状态机变更为"订单完成"(500)
系统更新服务评价状态为已完成
订单记录可能被同步到历史订单表 HistoryOrdersSync,为后续归档做准备

6.订单完成与关闭

订单正常完成或异常关闭处理:
正常流程:评价完成后订单状态为"订单完成"(500),表示整个订单生命周期结束
异常流程:
用户主动取消订单时,通过 OrderCancelDTO 封装取消信息,使用 OrderCancelStrategyManager 选择合适的取消策略处理
运营人员在管理端取消订单时,同样通过策略管理器处理
系统检测到超时未处理的订单可能被自动关闭,状态变更为"已关闭"(700)
完成的订单会在15天后被同步到 HistoryOrdersSync 表,再通过canal同步到历史订单库中

特殊处理流程

1.退款流程

用户申请退款时系统创建 OrdersRefund 记录,记录退款原因、金额等信息
系统跟踪退款状态直至完成,包括退款申请、审核、执行等环节
退款完成后更新订单退款状态和相关信息
订单取消流程
根据取消方(用户、运营、系统)和取消原因使用不同的取消策略
通过 OrderCancelStrategyManager 管理多种取消场景,如用户主动取消、超时取消等
记录详细的取消信息到 OrdersCanceled 表,包括取消人、取消原因、取消时间等
异常处理
服务超时、违约等异常情况会被记录到 BreachRecord 中,用于后续统计分析
系统通过状态机 OrderStateMachine 确保订单状态转换的准确性和一致性
各种订单状态变更事件通过 OrderStatusChangeEventEnum 枚举进行统一管理

2.订单状态管理

通过状态机严格控制订单状态流转
每个状态变更都对应特定的Handler处理业务逻辑
状态变更过程使用分布式事务保证数据一致性

遇到的主要问题及解决方案

1.订单查询性能问题

问题: 随着订单数据量增长,查询接口响应时间不及时,用户体验不好。
解决方案:
对Orders表的关键查询字段(如userId、ordersStatus、createTime)建立复合索引
实现滚动分页查询,避免使用OFFSET/LIMIT方式
对高频查询结果进行缓存,设置合理的过期时间

2.订单状态一致性问题

问题: 在分布式环境下,订单状态变更涉及多个服务调用,容易出现状态不一致的情况。
解决方案:
引入Seata分布式事务,在关键状态变更操作上保证ACID特性
使用状态机模式,严格控制状态流转路径,防止非法状态变更
在OrderStateMachine中定义合法的状态转换关系,确保每次变更都符合业务规则

3.订单取消/退款的复杂处理

问题: 不同状态下取消订单的处理逻辑差异很大,退款流程复杂。
解决方案:
使用策略模式将订单取消分为不同的策略统,一使用OrderCancelStrategy调用

退款流程独立处理,通过OrdersRefund表跟踪退款状态

根据订单状态和预约时间判断取消类型,直接取消 或者进入退款流程

4.高并发场景下的超卖问题

问题: 热门服务在同一时间可能被大量用户下单,导致的库存数量已经不足但是仍然可以购买的问题 。
解决方案:
在下单环节增加库存预占机制
使用Redis分布式锁控制同一服务项在同一时间段内的下单数量
在支付成功后再真正扣减库存,支付超时自动释放预占库存

性能优化

1.代码层面优化

使用MyBatis-Plus减少重复的DAO代码
通过DTO转换避免暴露数据库实体类
合理使用批量操作,减少数据库交互次数

使用xxljob定时任务处理订单超时需要取消的状态修改等问题

2.数据库层面优化

根据查询数据字段的频率进行分库分表,实现冷热分离大福提高数据库的查询效率

3.缓存优化

使用Redis缓存热门服务项信息、配置信息
对订单详情等读多写少的数据进行缓存
实现缓存穿透、击穿、雪崩的防护机制

4.异步处理

将非核心业务逻辑(如发送通知、更新统计数据)改为异步处理
使用RabbitMQ消息队列解耦服务之间的直接调用
对耗时操作(如生成报表)采用定时任务异步执行

http://www.hskmm.com/?act=detail&tid=19434

相关文章:

  • 课后作业小结
  • 课后3
  • 尝试决定
  • 竞赛第一步----进实验室
  • Java语法基础课程动手动脑与实验问题深度解析
  • lc1038-从二叉搜索树到更大和树
  • 课程中的问题
  • 课后2
  • Java语法基础课程“动手动脑”问题与实验整理
  • 课后感想
  • mysql的单表如何仅保留半年的数据
  • Java基础核心问题 链接版
  • java作业
  • Insightly存储型XSS漏洞分析:通过链接名称注入恶意脚本
  • H3C交换机的配置学习-01
  • Python脚本生成包含标准的#ifndef保护宏的头文件
  • java实验作业和动手动脑
  • (第三次)Numpy Pandas
  • sg.帮我写一个类似于vb6窗体设计的PySimpleGUI布局设计助手
  • ABC325EF 题解
  • Win11 安装 Python
  • mysql的单表多大要考虑分库分表
  • 2025 采购传感器不踩坑!国内传感器优秀厂家清单:解决精度,防爆,极端环境难题
  • sg.有没有一个可视化辅助设计pysimplegui布局的小工具?
  • 无刷电机速度闭环控制
  • sg.如何使用PySimpleGUI调试器实时监控变量
  • 微信小程序云开发 授权手机号快捷登陆
  • newDay05
  • AtCoder Beginner Contest 425 ABCDEF 题目解析
  • sg.如何使用PySimpleGUI调试器窗口