html5网站开发demo,XART视频库WordPress,门户网站建设一般多少钱,wordpress如何添加搜索到主菜单其他方案
1.事务状态表调⽤⽅重试接收⽅幂等
介绍
调⽤⽅维护⼀张事务状态表#xff08;或者说事务⽇志、⽇志流⽔#xff09;#xff0c;在每次调⽤之前#xff0c;落盘⼀条事务流⽔#xff0c;⽣成⼀个全局的事务ID
事务开始之前的状态是Begin#xff0c;全部结束之…其他方案
1.事务状态表调⽤⽅重试接收⽅幂等
介绍
调⽤⽅维护⼀张事务状态表或者说事务⽇志、⽇志流⽔在每次调⽤之前落盘⼀条事务流⽔⽣成⼀个全局的事务ID
事务开始之前的状态是Begin全部结束之后的状态是End。如果某个事务⼀直停留在Begin状态则说明该事务没有执⾏完毕
然后有⼀个后台任务扫描状态表在过了某段时间后假设1次事务执⾏成功通常最多花费30s状态没有变为最终的状态说明这条事务没有执⾏成功。于是重新调⽤系统的接口。保证这条流⽔的最终状态是End状态
事务状态表 补充说明
幂等问题系统调用方和被调用方根据全局的事务ID做幂等操作所以即使重复调⽤也没有关系如果后台任务重试多次仍然不能成功要为状态表加⼀个Error状态通过⼈⼯介⼊⼲预对于同步调⽤调⽤⽅调⽤A或B失败的时候可以重试三次。如果重试三次还不成功则放弃操作再交由后台任务后续处理
2.对账
介绍
所有的“过程”都必然产⽣“结果”过程是我们所说的“事务”结果就是业务数据。⼀个过程如果部分执⾏成功、部分执⾏失败则意味着结果是不完整的。从结果也可以反推出过程出了问题从⽽对数据进⾏修补这就是“对账”的思路
分类
全量对账⽐如每天晚上运作⼀个定时任务对比两个数据库增量对账可以是⼀个定时任务基于数据库的更新时间也可以基于消息中间件每⼀次业务操作都抛出⼀个消息到消息中间件然后由⼀个消费者消费这条消息对两个数据库中的数据进⾏⽐对当然消息可能丢失⽆法百分之百地保证还是需要全量对账来兜底
例子
案例1
电商⽹站的订单履约系统。⼀张订单从“已⽀付”到“下发给仓库”到“出仓完成”。假定从“已⽀付”到“下发给仓库”最多⽤1个⼩时从“下发给仓库”到“出仓完成”最多⽤8个⼩时。意味着只要发现1个订单的状态过了1个⼩时之后还处于“已⽀付”状态就认为订单下发没有成功需要重新下发也就是“重试”。同样只要发现订单过了8个⼩时还未出仓这时可能会发出报警仓库的作业系统是否出了问题……诸如此类
案例2
微博的关注关系。需要存两张表⼀张是关注表⼀张是粉丝表这两张表各⾃都是分库分表的。假设A关注了B需要先以A为主键进⾏分库存⼊关注表再以B为主键进⾏分库存⼊粉丝表。也就是说⼀次业务操作要向两个数据库中写⼊两条数据如何保证原⼦性
案例3
电商的订单系统也是分库分表的。订单通常有两个常⽤的查询维度⼀个是买家⼀个是卖家。如果按买家分库按卖家查询就不好做如果按卖家分库按买家查询就不好做。这种通常会把订单数据冗余⼀份按买家进⾏分库分表存⼀份按卖家再分库分表存⼀份。和案例2存在同样的问题⼀个订单要向两个数据库中写⼊两条数据如何保证原⼦性
案例2和3的解决思路
如果把案例 2、案例 3 的问题看作为⼀个分布式事务的话可以⽤对账解决
因为两个库的数据是冗余的可以先保证⼀个库的数据是准确的以该库为基准校对另外⼀个库
总结
对账的关键是要找出“数据背后的数学规律”。有些规律⽐较直接谁都能看出来⽐如案例2、案例3的冗余数据库有些规律隐含⼀些⽐如案例1的订单履约的状态。找到了规律就可以基于规律进⾏数据的⽐对发现问题然后补偿
3.弱⼀致性基于状态的补偿
场景 需求解析
对于该需求有⼀个关键特性对于电商的购物来讲允许少卖但不能超卖。⽐如有100件东西卖给99个⼈有1件没有卖出去这是可以接受的但如果卖给了101个⼈其中1个⼈拿不到货平台违约这就不能接受。⽽该处就利⽤了这个特性
流程
提交订单成功扣库存成功返回成功提交订单成功扣库存失败返回失败调⽤⽅重试此处可能会多扣库存提交订单失败不再扣库存调⽤⽅重试
解决
只要最终保证库存可以多扣不能少扣即可
但是库存多扣了数据不⼀致怎么补偿呢
库存每扣⼀次都会⽣成⼀条流⽔记录。这条记录的初始状态是“占⽤”等订单⽀付成功后会把状态改成“释放”
对于那些过了很长时间⼀直是占⽤⽽不释放的库存要么是因为前⾯多扣造成的要么是因为⽤户下了单但没有⽀付
通过⽐对得到库存系统的“占⽤又没有释放的库存流⽔”与订单系统的未⽀付的订单就可以回收这些库存同时把对应的订单取消。类似12306⽹站过⼀定时间不⽀付订单会取消将库存释放
4.重试回滚报警⼈⼯修复
先扣库存后创建订单。不做状态补偿为库存系统提供⼀个回滚接口。创建订单如果失败了先重试。如果重试还不成功则回滚库存的扣减。如回滚也失败则发报警进⾏⼈⼯⼲预修复
总之根据业务逻辑通过三次重试或回滚的⽅法最⼤限度地保证⼀致。实在不⼀致就发报警让⼈⼯⼲预。只要⽇志流⽔记录得完整⼈⼯肯定可以修复通常只要业务逻辑本⾝没问题重试、回滚之后还失败的概率会⽐较低所以这种办法虽然丑陋但很实⽤
