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

[yibo2018]

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

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

[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 进行第二次保障的