柳市网站托管,如何搭建手机网站,云计算网络架构包括哪些域,网站空间去哪里买的事务 1 本地事务1.1 事务的特性1.2 事务的隔离级别1.3 事务的传播属性 2 分布式事务2.1 分布式事务基础2.1.1 CAP定理2.1.2 BASE定理 2.2 分布式事务的解决方案2.2.1 两阶段提交#xff08;2PC#xff09;2.2.2 TCC补偿式事务2.2.3 消息事务最终一致性 1 本地事务
1.1 事务的… 事务 1 本地事务1.1 事务的特性1.2 事务的隔离级别1.3 事务的传播属性 2 分布式事务2.1 分布式事务基础2.1.1 CAP定理2.1.2 BASE定理 2.2 分布式事务的解决方案2.2.1 两阶段提交2PC2.2.2 TCC补偿式事务2.2.3 消息事务最终一致性 1 本地事务
1.1 事务的特性
事务的概念事务是逻辑上一组操作组成这组操作各个逻辑单元要么一起成功要么一起失败。
事务的四个特性ACID 1原子性(atomicity)“原子”的本意是“不可再分”事务的原子性表现为一个事务中涉及到的多个操作在逻辑上缺一不可。事务的原子性要求事务中的所有操作要么都执行要么都不执行。 2一致性(consistency)一致指的是数据的一致具体是指所有数据都处于满足业务规则的一致性状态。一致性原则要求一个事务中不管涉及到多少个操作都必须保证事务执行之前数据是正确的事务执行之后数据仍然是正确的。如果一个事务在执行的过程中其中某一个或某几个操作失败了则必须将其他所有操作撤销将数据恢复到事务执行之前的状态这就是回滚。 3隔离性(isolation)在应用程序实际运行过程中事务往往是并发执行的所以很有可能有许多事务同时处理相同的数据因此每个事务都应该与其他事务隔离开来防止数据损坏。隔离性原则要求多个事务在并发执行过程中不会互相干扰。 4持久性(durability)持久性原则要求事务执行完成后对数据的修改永久的保存下来不会因各种系统错误或其他意外情况而受到影响。通常情况下事务对数据的修改应该被写入到持久化存储器中。
1.2 事务的隔离级别
事务并发引起一些读的问题
脏读 一个事务可以读取另一个事务未提交的数据不可重复读 一个事务可以读取另一个事务已提交的数据 单条记录前后不匹配虚读幻读 一个事务可以读取另一个事务已提交的数据 读取的数据前后多了点或者少了点
并发写使用mysql默认的锁机制独占锁
解决读问题设置事务隔离级别
read uncommitted(0)read committed(2)repeatable read(4)Serializable(8)
隔离级别越高性能越低。 一般情况下脏读是不可允许的不可重复读和幻读是可以被适当允许的。
1.3 事务的传播属性
Spring中的7个事务传播行为:
事务行为说明PROPAGATION_REQUIRED支持当前事务假设当前没有事务。就新建一个事务PROPAGATION_SUPPORTS支持当前事务假设当前没有事务就以非事务方式运行PROPAGATION_MANDATORY支持当前事务假设当前没有事务就抛出异常PROPAGATION_REQUIRES_NEW新建事务假设当前存在事务。把当前事务挂起PROPAGATION_NOT_SUPPORTED以非事务方式运行操作。假设当前存在事务就把当前事务挂起PROPAGATION_NEVER以非事务方式运行假设当前存在事务则抛出异常PROPAGATION_NESTED如果当前存在事务则在嵌套事务内执行。如果当前没有事务则执行与PROPAGATION_REQUIRED类似的操作。
2 分布式事务
2.1 分布式事务基础
2.1.1 CAP定理
分布式存储系统的CAP原理分布式系统的三个指标 1Consistency一致性在分布式系统中的所有数据备份在同一时刻是否同样的值。对于数据分布在不同节点上的数据来说如果在某个节点更新了数据那么在其他节点如果都能读取到这个最新的数据那么就称为强一致如果有某个节点没有读取到那就是分布式不一致。
2 Availability可用性在集群中一部分节点故障后集群整体是否还能响应客户端的读写请求。要求数据需要备份
3Partition tolerance分区容忍性大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区partition。分区容错的意思是区间通信可能失败。 CAP理论就是说在分布式存储系统中最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题所以分区容忍性是我们无法避免的。所以我们只能在一致性和可用性之间进行权衡没有系统能同时保证这三点。要么选择CP、要么选择AP。
2.1.2 BASE定理 BASE是对CAP中一致性和可用性权衡的结果其来源于对大规模互联网系统分布式实践的结论是基于CAP定理逐步演化而来的其核心思想是即使无法做到强一致性Strong consistency但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性Eventual consistency。接下来看看BASE中的三要素
1Basically Available基本可用基本可用是指分布式系统在出现故障的时候允许损失部分可用性即保证核心可用。电商大促时为了应对访问量激增部分用户可能会被引导到降级页面服务层也可能只提供降级服务。这就是损失部分可用性的体现。
2Soft state软状态软状态是指允许系统存在中间状态而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
3Eventually consistent最终一致性最终一致性是指系统中的所有数据副本经过一定时间后最终能够达到一致的状态。弱一致性和强一致性相反最终一致性是弱一致性的一种特殊情况。
BASE模型是传统ACID模型的反面不同于ACIDBASE强调牺牲高一致性从而获得可用性数据允许在一段时间内的不一致只要保证最终一致就可以了。
2.2 分布式事务的解决方案
主流的解决方案如下 1 基于XA协议的两阶段提交2PC 2柔性事务-TCC事务 3柔性事务-最终一致性
2.2.1 两阶段提交2PC 2PC即两阶段提交协议是将整个事务流程分为两个阶段准备阶段Prepare phase、提交阶段commit phase2是指两个阶段P是指准备阶段C是指提交阶段。
第一阶段 事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作并反映是否可以提交.
第二阶段 事务协调器要求每个数据库提交数据。
其中如果有任何一个数据库否决此次提交那么所有数据库都会被要求回滚它们在此事务中的那部分信息。
目前主流数据库均支持2PC【2 Phase Commit】
XA 是一个两阶段提交协议又叫做 XA Transactions。 总的来说XA协议比较简单而且一旦商业数据库实现了XA协议使用分布式事务的成本也比较低。但是XA也有致命的缺点那就是性能不理想特别是在交易下单链路往往并发量很高XA无法满足高并发场景。
1 两阶段提交涉及多次节点间的网络通信通信时间太长 2事务时间相对于变长了锁定的资源的时间也变长了造成资源等待时间也增加好多。 3 XA目前在商业数据库支持的比较理想在mysql数据库中支持的不太理想mysql的XA实现没有记录prepare阶段日志主备切换会导致主库与备库数据不一致。许多nosql也没有支持XA这让XA的应用场景变得非常狭隘。
2.2.2 TCC补偿式事务
TCC 是一种编程式分布式事务解决方案。
TCC 其实就是采用的补偿机制其核心思想是针对每个操作都要注册一个与其对应的确认和补偿撤销操作。TCC模式要求从服务提供三个接口Try、Confirm、Cancel。
Try 主要是对业务系统做检测及资源预留Confirm 真正执行业务不作任何业务检查只使用Try阶段预留的业务资源Confirm操作满足幂等性。Cancel 释放Try阶段预留的业务资源Cancel操作满足幂等性。
整个TCC业务分成两个阶段完成
第一阶段 主业务服务分别调用所有从业务的try操作并在活动管理器中登记所有从业务服务。当所有从业务服务的try操作都调用成功或者某个从业务服务的try操作失败进入第二阶段。
第二阶段 活动管理器根据第一阶段的执行结果来执行confirm或cancel操作。如果第一阶段所有try操作都成功则活动管理器调用所有从业务活动的confirm操作。否则调用所有从业务服务的cancel操作。
缺点
Canfirm和Cancel的幂等性很难保证。这种方式缺点比较多通常在复杂场景下是不推荐使用的除非是非常简单的场景非常容易提供回滚Cancel而且依赖的服务也非常少的情况。这种实现方式会造成代码量庞大耦合性高。而且非常有局限性因为有很多的业务是无法很简单的实现回滚的如果串行的服务很多回滚的成本实在太高。
2.2.3 消息事务最终一致性 基于消息中间件的两阶段提交往往用在高并发场景下将一个分布式事务拆成一个消息事务A系统的本地操作发消息B系统的本地操作其中B系统的操作由消息驱动只要消息事务成功那么A操作一定成功消息也一定发出来了这时候B会收到消息去执行本地操作如果本地操作失败消息会重投直到B操作成功这样就变相地实现了A与B的分布式事务。
虽然上面的方案能够完成A和B的操作但是A和B并不是严格一致的而是最终一致的我们在这里牺牲了一致性换来了性能的大幅度提升。当然这种玩法也是有风险的如果B一直执行不成功那么一致性会被破坏具体要不要用还是得看业务能够承担多少风险。
适用于高并发最终一致 低并发基本一致二阶段提交 高并发强一致没有解决方案
