事务的ACID原则:
1. 原子性:事务中的所有操作要么同时成功,要么同时失败。
2. 隔离性:对同一资源操作的事务不能同时发生。
3. 一致性:要保证数据库内部完整性约束,声明性约束。
4. 持久性:对数据库做的一切修改将永久保存,不过是否出现故障。
1.分布式事务
在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。
分布式事务问题产生的原因就是每一个 服务都是 独立的,每一个服务的 事务也都是 独立地。
2.解决分布式事务的理论基础
CAP定理
分布式系统有三个指标:
1.Consistency(一致性):
用户访问分布式系统的任意节点,得到的数据必须一致。
2.Availability(可用性):
用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
Partition tolerance(分区容错性):
Partition(分区):因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接,形成独立分区。
tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务。
但是分布式系统无法同时满足这三个指标,这个结论叫做CAP定理。
总结:
分布式系统节点通过网络连接,一定会出现分区问题(P),当出现分区问题时,系统的一致性(C)和可用性(A)就无法同时满足。
拓展:
elasticsearch集群是CP还是AP?
当网络出现故障时,有节点和其他节点断开连接的时候,我们的es集群处于一个警告的状态,那个出现了故障的节点过了一段时间以后就会从集群中剔除,而这个节点上原来的数据分片会分散到其他健康的节点上去,保证数据的一致,因此是低可用性,高一致性,属于CP。
BASE理论
是对CAP的一种解决思路,包括三个思想
Basically Available(基本可用):分布式系统在出现故障时,允许损失部
分可用性,即保证核心可用。
Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不
一致状态。
Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软
状态结束后,最终达到数据一致。
分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论:
AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
解决分布式事务,各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致:
需要一个事务协调者来协调每一个事务的参与者(子系统事务)。这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。
总结:
全局事务:整个分布式事务
分支事务:分布式事务中包含的每个子系统的事务
最终一致思想:各分支事务分别执行并提交,如果有不一致的情况,再想办法恢复数据。
强一致思想:各个分支事务执行完业务不要提交,等待彼此结果。而后统一提交或回滚。
3.Seata
开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。 http://seata.io/
Seata事务管理中有三个重要的角色
TC-事务协调者 |
维护全局和分支事务的状态,协调全局事 |