有了域名和主机怎么做网站,初中毕业怎么样提升学历,建设网站终身免费,网站企划设计公司分布式事务严谨的定义#xff1a;分布式环境下的事务处理机制
CAP定理#xff1a;在一个分布式系统中#xff0c;涉及共享数据问题时#xff0c;以下三个特性最多只能同时满足两个 一致性#xff1a;代表数据在任何时刻、任何分布式节点中看到的都是符合预期的#xff0…分布式事务严谨的定义分布式环境下的事务处理机制
CAP定理在一个分布式系统中涉及共享数据问题时以下三个特性最多只能同时满足两个 一致性代表数据在任何时刻、任何分布式节点中看到的都是符合预期的一致性概念在分布式研究中是有严肃定义和多种细分类型的概念与分布式共识算法中的面向副本复制的一致性不同此处指的是面向数据库状态的一致性。 可用性代表系统不间断的提供服务的能力与其密切相关的两个指标为可用性和可维护性。可靠性使用平均无故障时间来度量可维护性用平均可修复时间来度量 分区容忍性代表分布式环境中部分节点因为网络原因而彼此失联后即与其他节点形成“网络分区时”系统仍能正确地提供服务的能力。
选择放弃一致性的AP系统是目前设计分布式系统的主流选择因为 1、P是分布式网络的天然属性永远可靠的通信在分布式系统中必定不成立这不是设计者想不想的问题而是只要用到网络来共享数据分区现象就会始终存在目前条件下无论如何设计也无法避免P的出现。 2、A是建设分布式系统的目的如果可用性随着节点数量增加反而降低的话很多分布式系统就失去了价值。除非是银行、证券这些涉及金钱交易的服务宁可中断也不能出错否则多数系统是不能容忍节点越多可用性反而越低的。
需要注意的是CAP和ACID理论中的一致性称为强一致性或者在线一致性。无论如何我们建设信息系统终究还是要确保操作结果至少在最终交付的时候是正确的解读允许数据在中间过程中出错不一致 但应该在输出时被修正过来。因此在牺牲了C的AP系统中要尽可能地获得正确的结果的行为称为追求“弱一致性”。在强一致性和弱一致性之间还存在着最终一致性如果数据在一段时间内没有被另外的操作所更改那么它最终会达到与强一致性过程相同的结果。面向最终一致性的算法也被称为“乐观复制算法”。
TCC分布式事务机制TCC由“try-confirm-cancel”三个单词缩写而成。如同TCC名字所示它分为如下三个过程 1、Try尝试执行阶段完成所有业务可执行性的检查保障一致性并且预留好全部需要用到的业务资源保障隔离性 2、Confirm阶段确认执行阶段不进行任何业务检查直接使用Try阶段准备的资源来完成业务处理。Confirm阶段可能会重复执行失败重试导致的因此本阶段所执行的操作需要具备幂等性即多次执行结果和执行一次的结果相同 3、Cancel阶段取消执行阶段释放Try阶段预留的业务资源。Cancel阶段也可能会重复执行因此也需要满足幂等性。
TCC其实有点类似于2PC的准备阶段和提交阶段但是TCC位于用户代码层面即业务代码写业务代码的程序员相对于基础库而言都是用户而不是基础设施层面。
TCC业务侵入性和开发成本都很高所以一般我们不会完全靠裸编码实现TCC而是会借助一些分布式事务中间件去完成尽可能地减轻编码工作量。
SAGA事务TCC事务是常见柔性事务中性能最高的但是它并不能满足所有场景因此有了SAGA事务。SAGA事务的设计思路把一个大事务分解目的是为了避免大事务长时间锁定数据库的资源。 SAGA由两部分操作组成 1、大事务拆分成若干个小事务整个分布式事务T分解成n个子事务命名为……。每个子事务都应该是或者能被视为是原子行为。如果分布式事务能够正常提交其对数据的影响最终一致性应与连续按顺序成功提交 等价。 2、为每个子事务设计一个对应的补偿动作命名为。与需要满足如下条件1与都具备幂等性2与满足交换律即无论是先执行还是其效果都是一样的3必须能成功提交即不考虑本身提交失败回滚的情形如出现本身提交失败就必须持续重试直至成功或者人工介入。
如果到均成功提交那么事务顺利完成否则就需要采用正向恢复策略或者反向恢复策略。
正向恢复Forward Recovery 如果事务提交失败则一直对进行重试直到成功为止最大努力交付这种恢复方式不需要补偿适用于事务最终都要成功的场景正向恢复的执行模式为失败,重试,。
反向恢复Backward Recovery:如果事务提交失败则一直执行对进行补偿直到成功为止最大努力交付。这里要求可通过持续重试必须执行成功。反向恢复的执行模式为(失败),(补偿),。
SAGA必须保证所有子事务都得以提交或者补偿但实际SAGA系统本身也有可能会崩溃所以他必须被设计成数据库类似的日志机制以保证系统恢复后可以追踪到子事务的执行情况。例如直行道哪一步或者补偿到哪一步了。
