dw做网站 后台用什么后台,wordpress 评论框 美化,系统开发的步骤,wordpress主题管理插件事务就是一个会话过程中#xff0c;对上下文的影响是一致的#xff0c;要么所有的更改都做了#xff0c;要么所有的更变都撤销掉。就要么生#xff0c;要么死。没有半死不死的中间不可预期状态。参考下薛定谔的猫。 事务是为了保障业务数据的完整性和准确性的。分布式事务对上下文的影响是一致的要么所有的更改都做了要么所有的更变都撤销掉。就要么生要么死。没有半死不死的中间不可预期状态。 参考下薛定谔的猫。 事务是为了保障业务数据的完整性和准确性的。 分布式事务常见的两个处理办法就是两段式提交和补偿。两段式提交典型的就是XA有个事务协调器告诉大家来都准备好提交大家回复都准备好了然后协调器告诉大家一起提交大家都提交了。补偿比较好理解先处理业务然后定时或者回调里检查状态是不是一致的如果不一致采用某个策略强制状态到某个结束状态一般是失败状态然后就世界太平了。典型的就是冲正操作。 准备好了以后如果没有问题收到提交所有人都开始提交。 这个时候比如对数据库来说有redo日志的。 如果某个数据库这时候宕机了那么它重启的时候先执行检查也会把上一次的这些操作都提交掉的。所以各个点的数据都是一致的。 问题 1比如 一个业务要调用很多的服务都是写操作如果有其中一个写的服务失败了怎么办 假设 4个写的吧有2个写失败了 。kimmking淘宝之类的网站一般的做法是如果4个都成功才算成功那么这次提交时4个写都设置成一个中间状态先容许不一致。然后4个执行完成了以后回调或是定时任务里检查这4个数据是不是一致的如果一致就全部置为成功状态如果不一致就全部置为失败。 复 杂的业务交互过程中不建议使用强一致性的分布式事务。解决分布式事务的最好办法就是不考虑分布式事务。就像刚说的问题一样把分布式的事务过程拆解成多 个中间状态中间状态的东西不允许用户直接操作等状态都一致成功或者检测到不一致的时候全部失败掉。就解耦了这个强一致性的过程。 一般情况下准实时就成了。涉及到钱有时候也可以这么搞。 淘宝几s内完整一个订单处理不是什么问题吧。 银行也不是全部都强一致性。也会扎差也会冲正。 特别是涉及到多个系统的时候我们比如买机票支付完成以后只支付完成状态然后返回给用户了我们过几分钟再刷新页面才会看到变成已出票订单完成状态。 这个时候如果我们要求所有处理都是强一致性的那么久完蛋了。页面要死在那儿几分钟才把这个事务处理完成返回给用户。 这样就肯定涉及一个问题支付了但是最终出票没出来。那就没办法商量换票或退款。 淘宝的订单改成出票失败给支付发消息通知退款。 慢的时候有可能是手工出票这时出一张票半小时都可能如果要求都必须强一致性的话所有处理线程都挂在哪儿系统早就完蛋了。 解决分布式事务的最好办法就是不考虑分布式事务。 拆分大的业务流程转化成几个小的业务流程然后考虑最终一致性。 问题2分布式事务是你们自己开发的还是数据库自带的 kimmking 1、只要一个处理逻辑能保证要么成功要么跟什么也没做一样都算是事务。数据库事务MQ也有事务。 你自己甚至可以写个程序生成两个文件要么都生成了要么都删掉不留痕迹这也算是事务。 2、分布式事务这一块有个XA规范实现XA接口的事务都可以加入到一个分布式事务中被XA容器管理起来。 3、补偿的办法需要具体情况具体分析没有一个各种场合都适用的框架。 转载于:https://www.cnblogs.com/longshiyVip/p/5199443.html
