V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yibo2018
V2EX  ›  程序员

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

  •  
  •   yibo2018 · 185 天前 · 2544 次点击
    这是一个创建于 185 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  184 天前
    看到很多收藏,回复却很少
    我认为收藏是无效动作,要让我做个论坛,一定要把收藏删掉
    第 2 条附言  ·  184 天前
    2022.06.08 更新
    整体流程参考拼多多(无购物车模式)
    修改第五步,同时对第五步的性能问题表示担忧

    感谢 @showshowcode 大兄弟
    29 条回复    2022-06-09 09:27:25 +08:00
    showshowcode
        1
    showshowcode  
       185 天前   ❤️ 1
    emm 你的库存 啥的呢 价格满减活动 然后才是支付啥的吧 看你什么业务了 有的还有更多返佣啥的 如果只是单纯订单中主要涉及的就是订单的落库 查询 状态流转 比如退款发货啥的
    AnroZ
        2
    AnroZ  
       185 天前
    没涉及过订单业务,纯好奇看了下。
    1. MQ (肯定是性能大瓶颈),2. 超时判断支付(防止并发冲突误判)
    这两点需谨慎设计下
    rowe
        3
    rowe  
       184 天前
    1.支付前就应该写入订单数据到 db ,俗称落单据,这里要注意进行读写分离并分表
    2.不应该使用 redis 做库存校验,这里涉及到锁定库存的问题,电商系统一般分 BC 端,买家在下单的同时,运营人员也会在 B 端对库存进行调整,使用 redis 虽然解决了性能问题但会带来两个新问题:
    ①如何将 B 端库存实施同步到 redis 并实现强一致
    ②如何锁库存
    实际上你很难做到这两点,而且生产过程中及难排查问题,比较常见的做法是数据库乐观锁加分库分表
    3.订单表应该分表
    rabbbit
        4
    rabbbit  
       184 天前
    问个问题,订单付款倒计时一般都是怎么做的?
    rabbbit
        5
    rabbbit  
       184 天前
    还有,用户发起退货时一般怎么处理流程,单独建退货表吗?
    DrX
        6
    DrX  
       184 天前
    @rabbbit
    非常简单。
    1. 创建订单的时候,先设定好“最迟支付时间”,然后返回给客户端,客户端自己计算时差并显示倒计时。
    2. 再然后支付的时候验证当前时间是否小于“最迟支付时间”就可以了。
    brust
        7
    brust  
       184 天前
    @rabbbit
    可以考虑用延迟队列
    yibo2018
        8
    yibo2018  
    OP
       184 天前
    @showshowcode 库存在第二步,通过 redis 去判断
    价格满减在第三步的时候可以判断
    返佣之类的就是完全下游业务,在第八步完成
    我有点没看懂,你的疑惑点在哪
    yibo2018
        9
    yibo2018  
    OP
       184 天前
    @AnroZ
    1. MQ (肯定是性能大瓶颈)-- 同意
    2. 超时判断支付(防止并发冲突误判)
    如果点开支付不输入密码直接退出,第四步的延时任务可以判断
    如果点开支付等到支付过期再输入密码,一般来说第三方支付的接口会直接返回支付超时,或者也可以再 6.5 步之后的支付回调做判断
    yibo2018
        10
    yibo2018  
    OP
       184 天前
    @rowe
    1. 是的可以在 6 步存入数据库,但我认为可以省去,在真正付款的时候再落库,会有什么问题吗?另外读写分离分表是必须的,这方面我再补充下

    2. 这个问题我确实没想过,很提神哈哈,我试着回答下
    2.1 redis 端的 increment 应该就可以实现
    2.2 锁库存是什么意思?为什么要锁?没明白
    2.3 对于大厂的秒杀活动,是用 redis 吗?
    2.4 对于大厂的日常商品售卖,我觉得也是用数据库乐观锁 update stock - 1 where stock > 0
    yibo2018
        11
    yibo2018  
    OP
       184 天前
    @rabbbit 订单付款倒计时一般都是怎么做的?
    分俩个层面
    1. 前端,在进入支付页的时候将倒计时显示
    2. 后端,这里可以做 2 层
    2.1 支付接口层级:一般支付宝等支付接口,都有支付超时的参数,可以设置
    2.2 自身系统层级:参考我的图,第四步,第 6.5 步,上面的回复有写
    yibo2018
        12
    yibo2018  
    OP
       184 天前
    @rabbbit 退货先不考虑物流层面,直接改订单状态就行
    单独建退货表,如果是 b 端销售的话,有必要?这点我也不了解
    xhinliang
        13
    xhinliang  
       184 天前
    支付的时候才落库,你这个好不专业啊,哈哈。
    showshowcode
        14
    showshowcode  
       184 天前   ❤️ 1
    纠正一个点 提单时候就要落库,简单的说支付前就要落库了
    yibo2018
        15
    yibo2018  
    OP
       184 天前
    @xhinliang 可以说说哪里不专业吗,我考虑了很多情况都不会有影响,反而可以增加并发
    yibo2018
        16
    yibo2018  
    OP
       184 天前
    @showshowcode 可以说理由吗
    loveyu
        17
    loveyu  
       184 天前
    我比较想看一个 10 并发的订单全流程图,有细节的那种
    showshowcode
        18
    showshowcode  
       184 天前   ❤️ 1
    @yibo2018 举个简单例子 你选品加完购物车点击提交的时候 最多也就是选择个支付方式 根本没到支付那步 ,这个叫提单 会有些商品满减等信息;
    支付那一步一般是收银台而且还可以选择支付方式,按照你的描述难道我不支付 我刚才提交的订单就没了?电商不是这么处理吧;
    而且订单核心就是落库和查询;所有状态都是 MQ 解耦的 我创建了订单 半个小时一个小时后再支付 这都正常 订单就是订单 不要跟其他的扯啥关系 都是接其它 MQ 触发变化
    fkdtz
        19
    fkdtz  
       184 天前
    楼主这套流程是线上在跑的,还是只在设计图纸里的
    binge921
        20
    binge921  
       184 天前
    http://blog.guopeibin.cn/xx.png
    这是我两年前写的 哈哈 大家可以一起看看
    yibo2018
        21
    yibo2018  
    OP
       184 天前
    @loveyu OK ,你可以说说步骤几,你觉得不够细节,我马上加
    yibo2018
        22
    yibo2018  
    OP
       184 天前
    @fkdtz 设计图纸,所以才需要找大家看看 (狗头)
    之前做过订单部分,所以比较清楚支付那里的细节
    yibo2018
        23
    yibo2018  
    OP
       184 天前
    @showshowcode
    1. 你选品加完购物车点击提交的时候(这里对应步骤三之后) 最多也就是选择个支付方式 根本没到支付那步 (确实没到,这里只是选择支付方式,确定满减之类的优惠之后的最终要付的钱,真正支付是在步骤 6)

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

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

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

    再次感谢
    yibo2018
        24
    yibo2018  
    OP
       184 天前
    @binge921 哇塞,你这个看起来就很强,可以发下 blog 完整链接吗
    loveyu
        25
    loveyu  
       184 天前   ❤️ 1
    @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
        26
    yibo2018  
    OP
       184 天前
    @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
        27
    showshowcode  
       184 天前   ❤️ 1
    高并发的手段其实大厂的也不复杂,主要抗量的都是中间件团队;电商大促一般都会把分支 MQ 暂时干掉 比如关闭退款窗口、小的活动、返佣,旁支的支付方式 也可以说是降级 把非主流程的都降了;
    还有延迟手段 挤压下单 or 支付成功 MQ 一点点的放量;也就是先提单 然后 支付成功直接就走正向流程 ;等到那十分钟过后 峰值退去 再把退款等非正常流程打开 再通过 MQ 处理 ;

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

    核心的订单、账单、支付 只要能写入就 OK 了 再狠一点 只要上传的 MQ 接受到 ACK 了 可能都不落库 只要 MQ 足够强大;比如支付成功只要消息存到 MQ 了 我库也可以不写 直接发 MQ 就行了 因为下游业务只需要被动接 MQ 所以支付的 MQ 就当数据库用了 后面只需要异步一份落库即可 ;
    showshowcode
        28
    showshowcode  
       184 天前   ❤️ 1
    你的图用在单商品上 可以
    echoZero
        29
    echoZero  
       183 天前   ❤️ 1
    曾经做过一个订单的系统的。有几点实际会用到,但是图上缺少
    1. 第 5 步 用户创建订单发起支付,这一步需要落库,确保数据不可丢
    1. 图中只有用户政策流程,没有任何异常流程对应的补偿机制
    1. 库存扣减 redis 只能第一重保险,后面是由 mysql 进行第二次保障的
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2526 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 57ms · UTC 16:06 · PVG 00:06 · LAX 08:06 · JFK 11:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.