024_分布式订单系统架构实战学习笔记
2022-04-03 17:44:35 1 举报AI智能生成
分布式订单系统架构实战学习笔记
作者其他创作
大纲/内容
原理
应用场景
AT 模式
TCC 模式
Saga 模式
Seata
分布式定时调度任务
性能压测
第一步，风控检查，用户参数合法检查
第二步，获取商品信息，计算订单价格
第三步，营销服务，锁定优惠券
第四步，库存服务，锁定库存
第五步，操作本地事务，完成订单创建
第六步，发送订单延迟消息，支付超时自动关单
业务流程
经典分布式事务问题，生单失败，导致数据不一致
引入 Seata AT 模式分布式事务
技术方案
技术问题
Seata AT模式分布式事务引入的缺陷1，基于业务分析，'库存锁定' 全局锁争用问题
技术方案存在的缺陷
引入RocketMQ事务消息机制，优化升级
第一步，注册开启全局事务，xid
第二步，注册分支事务，branch id
第三步，分支事务，执行 try 逻辑，预留资源
第四步，分支事务，try 逻辑执行成功，上报分支事务状态到Seata Server
提交分支事务，分支事务，commit，实际业务操作，事务提交成功
第五步，如果，所有分支事务的 try 逻辑全部执行成功
回滚分支事务，分支事务，cancel，预留资源逆向操作，事务提交失败
第六步，如果，存在分支事务的 try 逻辑执行失败，上报分支事务状态到Seata Server
实现机制：基于Seata TCC模式实现分布式事务
技术问题：空悬挂，空回滚
技术方案：本地缓存组件，记录Try操作的状态，记录空回滚记录
另外，库存更新逻辑优化升级，库存服务引入Redis缓存，异构存储，支撑秒杀、大促、抢购等场景
最大的好处就是避免库存锁定的全局锁争用问题
AT + TCC混合事务方案
补充一点，没有分布式事务机制的纯补偿方案，核心思想：基于操作日志记录进行比对，补偿处理
技术方案升级
创建订单
第一步，支付服务，发起预支付
第二步，调用第三方支付平台，发起支付
订单服务更新订单状态（已支付），投递’订单支付成功‘消息
订单服务的消费者后台线程，消费处理’订单支付成功‘消息，通知履约服务，订单支付完成
更新订单状态（已履约）
第三步，支付完成回调，通知订单服务
技术方案：分布式锁
经典重复支付问题
技术方案：延迟消息
订单支付完成消息处理问题
如何保证更新订单支付状态和发送“订单支付成功”消息的强一致性
双异步设计，同步调用履约服务改为发送“触发订单履约”消息，异步通知
如何保证订单服务“订单支付成功”消息的消费者，发送“触发订单履约”消息和更新订单履约状态的事务特性
触发订单履约机制系统性能问题
第一步，发送 half 消息
第二步，half 消息响应，如果失败，抛出异常，等待后面调用方再次调用
第三步，half 消息响应，如果成功，执行本地事务，本地事务执行成功，提交消息
第四步，half 消息响应，如果成功，执行本地事务，本地事务执行失败，回滚消息，删除消息
第五步，消息提交成功，执行后续业务逻辑
第六步，网络故障或者系统崩溃，RocketMQ 服务端回查事务状态，决定提交消息还是删除消息
基于 RocketMQ 事务消息机制
支付订单
调度出库，仓库操作员根据订单进行拣货出库，投递拣货出库完成的消息
物流配送，快递员将商品打包邮寄配送，投递物流配送完成的消息
完成签收，消费者最终完成签收，投递货品签收完成的消息
技术方案：订单哈希处理（保证分配到同一个ConsumerQueue） + 消费失败消息挂起机制
订单履约状态消息乱序问题
1. 履约服务，创建履约单
2. 通知仓储服务，调度出库发货
3. 通知物流服务，物流配送
回过头重新梳理一下订单履约业务
如何保证强一致性问题，Seata AT 模式，Seata TCC模式还适用么
目前仍然存在的缺陷
Seata Saga长事务
关注，空补偿问题
订单履约
正向业务流程
订单服务检查订单状态，是否支付，没有支付，更新订单状态，“已取消”
履约服务，通知仓储服务，拦截发货
履约服务，通知物流系统，拦截物流
履约服务，更新本地履约数据库
订单服务检查订单状态，是否支付，已经支付，订单系统同步通知履约系统，拦截履约，更新订单状态，“已取消”
库存系统，消费消息，释放库存
MySQL数据库和Redis缓存双写机制
发送消息（释放库存）
营销系统，消费消息，释放优惠券
发送消息（释放优惠券）
更新订单数据库，插入售后数据
订单服务，实际退款消费者，消费消息，调用支付系统，真正调用第三方平台系统，发起退款
订单服务，等待退款完成回调
发送消息，实际退款
订单服务，退款消费者，消费消息，检查订单状态，已经支付
双异步退款链路设计
发送消息（发起退款）
订单服务，内部释放资产消息消费者，消费消息，发送多路MQ
订单服务发送’释放资产‘消息，释放资产
重点关注订单已经支付的场景
拦截履约、取消订单与释放资产（消息投递）的强一致性事务
取消订单、拦截履约，使用Seata AT模式，刚性事务，全局事务，保证数据一致
第一步，发送 half 消息
响应失败，抛出异常，取消订单失败
本地刚性事务执行成功，提交消息，释放库存
本地刚性事务执行失败，回滚消息，取消订单失败
响应成功，执行本地刚性事务，取消订单、拦截履约
第二步，响应 half 消息
第三步，网络故障或者系统崩溃，RocketMQ 触发回查事务状态，决定提交消息还是删除消息
释放资产（消息投递），基于RocketMQ事务消息机制，二阶段提交，包裹取消订单、拦截履约刚性事务，最终数据一致
业务优化
同步调用
拦截履约
业务可扩展性实现
设计思想：业务Topic独立
分布式锁，状态检查
释放资产MQ多路推送的幂等性问题
事务消息
双异步退款链路的强一致问题
释放资产MQ多路推送机制
扩展性
响应时间，提升用户体验
异步化
消息不丢失
释放资产
设计亮点
超时自动取消订单
取消订单
用户消费者，发起退货申请
订单服务，操作本地数据库，记录售后数据，发送消息，退货申请，通知客服系统
客服服务，消费消息，插入售后工单，等待退货入库通知（空实现）
订单记录售后数据与发送消息通知客服系统的强一致性问题
基于RocketMQ事务消息保证
分布式锁，重复退货申请幂等保证
发起售后退货
客服服务，审核售后退货申请完成，通知订单服务更新售后数据
发送消息，释放库存
......
订单服务，消费消息，售后释放资产消费者
订单服务更新售后数据，发送消息，售后退货释放资产
订单服务更新售后数据与”发送售后释放资产消息“的强一致性问题
基于RocketMQ事务消息
订单服务，售后释放资产消费者，MQ多路推送，扩展性保障
审核售后退货
售后退货
订单支付，订单履约，仓库人员拣货出库，发现缺品
通知订单服务，仓储缺品退款
订单服务更新售后数据，发送消息，仓储缺品执行退款
订单服务更新售后数据和发送‘仓储缺品消息’执行退款逻辑的强一致性问题
缺品退款
逆向业务流程
高并发场景下 for 循环读写数据库
高并发场景下 for 循环 rpc 调用服务雪崩问题
代码重构之冗长方法抽取分离技巧
代码重构之分布式锁与幂等检查强关联
MQ事务消息整洁之道
代码坏味道
分布式订单系统架构实战
收藏
收藏
0 条评论
回复 删除
下一页
