整理了一个订单全流程图，希望各位大佬提提意见

[yibo2018]

https://efficacious-beginner-568.notion.site/d3d5c216e3314bc0aa5bb438806f0483

目的是支持百万级订单高并发

看到很多收藏，回复却很少
我认为收藏是无效动作，要让我做个论坛，一定要把收藏删掉

2022.06.08 更新
整体流程参考拼多多(无购物车模式)
修改第五步，同时对第五步的性能问题表示担忧

感谢 @showshowcode 大兄弟

[showshowcode]

emm 你的库存 啥的呢 价格满减活动 然后才是支付啥的吧 看你什么业务了 有的还有更多返佣啥的 如果只是单纯订单中主要涉及的就是订单的落库 查询 状态流转 比如退款发货啥的

[AnroZ]

没涉及过订单业务，纯好奇看了下。
1. MQ （肯定是性能大瓶颈），2. 超时判断支付（防止并发冲突误判）
这两点需谨慎设计下

[rowe]

1.支付前就应该写入订单数据到 db ，俗称落单据，这里要注意进行读写分离并分表
2.不应该使用 redis 做库存校验，这里涉及到锁定库存的问题，电商系统一般分 BC 端，买家在下单的同时，运营人员也会在 B 端对库存进行调整，使用 redis 虽然解决了性能问题但会带来两个新问题：
①如何将 B 端库存实施同步到 redis 并实现强一致
②如何锁库存
实际上你很难做到这两点，而且生产过程中及难排查问题，比较常见的做法是数据库乐观锁加分库分表
3.订单表应该分表

[rabbbit]

问个问题,订单付款倒计时一般都是怎么做的?

[rabbbit]

还有,用户发起退货时一般怎么处理流程,单独建退货表吗?

[y830CAa5nink4rUQ]

@rabbbit
非常简单。
1. 创建订单的时候，先设定好“最迟支付时间”，然后返回给客户端，客户端自己计算时差并显示倒计时。
2. 再然后支付的时候验证当前时间是否小于“最迟支付时间”就可以了。

[brust]

@rabbbit
可以考虑用延迟队列

[yibo2018]

@showshowcode 库存在第二步，通过 redis 去判断
价格满减在第三步的时候可以判断
返佣之类的就是完全下游业务，在第八步完成
我有点没看懂，你的疑惑点在哪

[yibo2018]

@AnroZ
1. MQ （肯定是性能大瓶颈）-- 同意
2. 超时判断支付（防止并发冲突误判）
如果点开支付不输入密码直接退出，第四步的延时任务可以判断
如果点开支付等到支付过期再输入密码，一般来说第三方支付的接口会直接返回支付超时，或者也可以再 6.5 步之后的支付回调做判断

[yibo2018]

@rowe
1. 是的可以在 6 步存入数据库，但我认为可以省去，在真正付款的时候再落库，会有什么问题吗？另外读写分离分表是必须的，这方面我再补充下

2. 这个问题我确实没想过，很提神哈哈，我试着回答下
2.1 redis 端的 increment 应该就可以实现
2.2 锁库存是什么意思？为什么要锁？没明白
2.3 对于大厂的秒杀活动，是用 redis 吗？
2.4 对于大厂的日常商品售卖，我觉得也是用数据库乐观锁 update stock - 1 where stock > 0

[yibo2018]

@rabbbit 订单付款倒计时一般都是怎么做的?
分俩个层面
1. 前端，在进入支付页的时候将倒计时显示
2. 后端，这里可以做 2 层
2.1 支付接口层级：一般支付宝等支付接口，都有支付超时的参数，可以设置
2.2 自身系统层级：参考我的图，第四步，第 6.5 步，上面的回复有写

[yibo2018]

@rabbbit 退货先不考虑物流层面，直接改订单状态就行
单独建退货表，如果是 b 端销售的话，有必要？这点我也不了解

[xhinliang]

支付的时候才落库，你这个好不专业啊，哈哈。

[showshowcode]

纠正一个点 提单时候就要落库，简单的说支付前就要落库了

[yibo2018]

@xhinliang 可以说说哪里不专业吗，我考虑了很多情况都不会有影响，反而可以增加并发

[yibo2018]

@showshowcode 可以说理由吗

[loveyu]

我比较想看一个 10 并发的订单全流程图，有细节的那种

[showshowcode]

@yibo2018 举个简单例子 你选品加完购物车点击提交的时候 最多也就是选择个支付方式 根本没到支付那步 ，这个叫提单 会有些商品满减等信息；
支付那一步一般是收银台而且还可以选择支付方式，按照你的描述难道我不支付 我刚才提交的订单就没了？电商不是这么处理吧；
而且订单核心就是落库和查询；所有状态都是 MQ 解耦的 我创建了订单 半个小时一个小时后再支付 这都正常 订单就是订单 不要跟其他的扯啥关系 都是接其它 MQ 触发变化

[fkdtz]

楼主这套流程是线上在跑的，还是只在设计图纸里的

[binge921]

http://blog.guopeibin.cn/xx.png
这是我两年前写的 哈哈 大家可以一起看看

[yibo2018]

@loveyu OK ，你可以说说步骤几，你觉得不够细节，我马上加

[yibo2018]

@fkdtz 设计图纸，所以才需要找大家看看 （狗头）
之前做过订单部分，所以比较清楚支付那里的细节

[yibo2018]

@showshowcode
1. 你选品加完购物车点击提交的时候（这里对应步骤三之后） 最多也就是选择个支付方式 根本没到支付那步 (确实没到，这里只是选择支付方式，确定满减之类的优惠之后的最终要付的钱，真正支付是在步骤 6)

2. 支付那一步一般是收银台而且还可以选择支付方式，（对应步骤三之后）按照你的描述难道我不支付 我刚才提交的订单就没了？电商不是这么处理吧；（确实，这里有问题（不支持支付超时后重新支付，所以落单是必要的），多谢！！！）

3. 而且订单核心就是落库和查询；所有状态都是 MQ 解耦的 我创建了订单 半个小时一个小时后再支付 这都正常 订单就是订单 不要跟其他的扯啥关系 都是接其它 MQ 触发变化

我理解这句话有一些意思是和 2 重复的,就是落单问题
其次这里用到的 MQ 都是为了削峰

再次感谢

[yibo2018]

@binge921 哇塞,你这个看起来就很强,可以发下 blog 完整链接吗

[loveyu]

@yibo2018
1. 用户填写地址，咋存储（这里可能有运营需求、统计需求）
2. 用户点击购买，这里一般 ABCD 各种灰度测试
3. 订单号（要给用户看的，不能长、不能短、整个公司多系统唯一）
4. 库存问题（锁定、绑定、取消）
5. 订单状态
6. 库存状态
7. 支付（支付宝、微信、其他支付），app 支付、小程序支付、网页支付、app 跳网页支付、app 跳小程序支付
8. MQ （状态、操作、统计、库存、渠道、财务）
9. 搜索
10. 售后
11. 补单
12. 数据修复
13. 报表
14. 对账
15. 导出
16. 通知
17. 权限
18. 数据安全
19. 第三方订单
20. 分销

[yibo2018]

@loveyu
1. 用户填写地址，咋存储（这里可能有运营需求、统计需求）

第一步，存入 redis ，第二步判断有货，用户进入选择支付方式页面，选择支付方式，进入步骤五，这里落库。具体信息可以步骤五的接口提供，也可以第一步中 redis 信息提取

2. 用户点击购买，这里一般 ABCD 各种灰度测试

abcd 灰度测试是啥。。。对不起

3. 订单号（要给用户看的，不能长、不能短、整个公司多系统唯一）

第一步雪花算法生成的 ID

4. 库存问题（锁定、绑定、取消）

锁定，绑定：第二步的 redis lua 脚本操作
取消：第四步的延时任务，如果到时间不是支付完成状态，或者订单不存在，直接回库存


5. 订单状态
初始（等待支付） - 支付成功 、失败、超时 - （物流状态，不讨论）

第四步判断是未支付或订单不存在
第五步初始状态
第七步支付成功状态


6. 库存状态

库存使用 MySQL - redis 同步去维护，redis 数据结构 ：goodsId + addressId : stocks
库存状态是什么意思

7. 支付（支付宝、微信、其他支付），app 支付、小程序支付、网页支付、app 跳网页支付、app 跳小程序支付

对接过支付宝，微信支付，流程都是一样的
其他支付没多大影响

8. MQ （状态、操作、统计、库存、渠道、财务）

没懂

9. 搜索

搜索订单？
入库的时候是根据 userID 分库分表的，对应 c 端用户，方便查询自己订单的状态信息
如果要做其他内部统计，那么应该在做一个数据层

10. 售后

订单状态可以延续

11. 补单

什么情况下要补单？

12. 数据修复

太宽泛了

13. 报表

需要做其他数据层统计

14. 对账

同上

15. 导出

同上

16. 通知

在需要通知的地方异步发延时任务就可以了，要注意幂等

17. 权限

设计后台管理系统了？

18. 数据安全

别人竞争对手通过订单 ID 窥探到你家的体量就行吧，必要时可以对输出订单 ID 再一层加密

19. 第三方订单

一样的逻辑，最好区别于自家订单，另外起表，但是整套的逻辑可以共用

20. 分销

分销分红？步骤八以后操作

[showshowcode]

高并发的手段其实大厂的也不复杂，主要抗量的都是中间件团队；电商大促一般都会把分支 MQ 暂时干掉 比如关闭退款窗口、小的活动、返佣，旁支的支付方式 也可以说是降级 把非主流程的都降了；
还有延迟手段 挤压下单 or 支付成功 MQ 一点点的放量；也就是先提单 然后 支付成功直接就走正向流程 ；等到那十分钟过后 峰值退去 再把退款等非正常流程打开 再通过 MQ 处理 ；

这里核心操作一般就是下单的 MQ 流量控制；支付 MQ 的流量控制；

核心的订单、账单、支付 只要能写入就 OK 了 再狠一点 只要上传的 MQ 接受到 ACK 了 可能都不落库 只要 MQ 足够强大；比如支付成功只要消息存到 MQ 了 我库也可以不写 直接发 MQ 就行了 因为下游业务只需要被动接 MQ 所以支付的 MQ 就当数据库用了 后面只需要异步一份落库即可 ；

[showshowcode]

你的图用在单商品上 可以

[echoZero]

曾经做过一个订单的系统的。有几点实际会用到，但是图上缺少
1. 第 5 步 用户创建订单发起支付，这一步需要落库，确保数据不可丢
1. 图中只有用户政策流程，没有任何异常流程对应的补偿机制
1. 库存扣减 redis 只能第一重保险，后面是由 mysql 进行第二次保障的