分布式事务产生背景
传统单体项目单库大部分情况下,不会产生分布式事务。但随着系统数据量增大,单个数据库承受越来越大压力,系统开始变慢,单库出现性能瓶颈。用户开始抱怨,慢慢当前系统结构开始无法适应业务发展。
技术服务于业务,系统跟着业务发展进行架构演进,原有的架构已无法满足业务现状,同时也带来新的挑战,公司对系统提出重构和优化,把原来单体系统切换成主流微服务架构,、分布式系统架构。根据不同的业务将拆分成不同的微服务,比如会员服务、订单服务、商品服务。同时每个微服务对应独立的数据,业务数据被分散到各个业务系统数据库中,用户在系统的一个操作行为数据被分散到各个独立的子系统,由单库操作变成跨库操作,这就产生了跨库操作的分布式事务问题。
场景1:系统微服务化,业务拆分成一个个独立的微服务,每个微服务都对应者一个独立的业务数据库,用户在系统的一个操作行为数据被分散到各个独立的子系统,形成垮库操作。
场景二:为了解决数据库上的瓶颈,分库是很常见的解决方案,不同用户就可能落在不同的数据库里,原来一个库里的事务操作,现在变成了跨数据库的事务操作
单体应用事务如何管理?
-
原子性(Atomicity) 事务是一个或者多个SQL语句组成的整体,要么全部执行成功,要么全都执行失败 ,事务执行之后,不允许停留在中间某个状态。
-
一致性(Consistency) 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。
-
隔离性(Isolation) 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。
-
持久性(Durability)一旦事务提交成功,事务中所有的数据操作都必须被持久化保存到数据库中,即使提交事务后,数据库崩溃,在数据库重启时,也必须能保证通过某种机制恢复数据。
事务隔离级别
事务管理方式
JDBC事务设置为手动提交模式
基于Spring事务管理器"注解事务"
分布式事务相关理论
CAP理论
分布式系统中:Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼,所以不要有妄想。
-
一致性:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致,所以,一致性,说的就是数据一致性。
-
可用性:在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性),CAP中的A指的是可用性(Availability),而ACID中的A指的是原子性(Atomicity)
-
分区容错性:即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。简单点说,就是在网络中断,消息丢失的情况下,系统如果还能正常工作,就是有比较好的分区容错性。
CAP取舍的策略(3选2)
CAP取舍的策略 3选2
在设计或开发分布式系统的时候,不可避免的要在CAP中做权衡。需要根据自己的系统的实际情况,选择最适合自己的方案,对于一个分布式系统来说。P是一个基本要求,CAP三者中,只能在CA两者之间做权衡,并且要想尽办法提升P,而非分布式系统有限考虑可用性和一致性
-
CA without P
分布式系统中几乎是不存在的。首先在分布式环境下,网络分区是一个自然的事实。因为分区是必然的,所以如果舍弃P,意味着要舍弃分布式系统。那也就没有必要再讨论CAP理论了。这也是为什么在前面的CAP证明中,我们以系统满足P为前提论述了无法同时满足C和A。
比如我们熟知的关系型数据库,如My Sql和Oracle就是保证了可用性和数据一致性,但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来
-
CP without A
如果一个分布式系统不要求强的可用性,即容许系统停机或者长时间无响应的话,就可以在CAP三者中保障CP而舍弃A。
一个保证了CP而一个舍弃了A的分布式系统,一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。
设计成CP的系统其实也不少,其中最典型的就是很多分布式数据库,他们都是设计成CP的。在发生极端情况时,优先保证数据的强一致性,代价就是舍弃系统的可用性。
如Redis、HBase等,还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
无论是像Redis、HBase这种分布式存储系统,还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用
-
AP wihtout C
要高可用并允许分区,则需放弃一致性。一旦网络问题发生,节点之间可能会失去联系。为了保证高可用,需要在用户访问时可以马上得到返回,则每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。
对于多数大型互联网应用的场景,主机众多、部署分散,而且现在的集群规模越来越大,所以节点故障、网络故障是常态,而且要保证服务可用性达到N个9,即保证P和A,舍弃C。12306买票当你购买的时候提示你是有票的(但是可能实际已经没票了)你也正常的去输入验证码,下单了。但是过了一会系统提示你下单失败,余票不足。这其实就是先在可用性方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,会影响一些用户体验,但是也不至于造成用户流程的严重阻塞。(舍弃的只是强一致性,退而求其次保证最终一致性)
小结
适合的才是最好的,对于涉及到钱财这样不能有一丝让步的场景,C必须保证。网络发生故障宁可停止服务,这是保证CP,舍弃A。比如前几年支付宝光缆被挖断的事件,在网络出现故障的时候,支付宝就在可用性和数据一致性之间选择了数据一致性,用户感受到的是支付宝系统长时间宕机,但是其实背后是无数的工程师在恢复数据,保证数据的一致性。
对于其他场景,比较普遍的做法是选择可用性和分区容错性,舍弃强一致性,退而求其次使用最终一致性来保证数据的安全
BASE理论
基本可用,最终一致
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果。理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。
Basically Available(基本可用):
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性
Soft state(软状态):
弱状态也称为软状态,和硬状态相对,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据监听过程存在延时。
Eventually consistent(最终一致性):
系统允许数据暂时不一致,只要程序保证最终一致性即可。例如银行系统的跨行转账业务
小结
BASE理论面向的是大型高可用可扩展的分布式系统,和传统事务的ACID特性相反的,它完全不同于ACID的强一致性模型,而是提出通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。但同时,在实际的分布式场景中,不同业务单元和组件对数据一致性的要求是不同的,因此在具体的分布式系统架构设计过程中,ACID特性与BASE理论往往又会结合在一起使用。观看下一篇
下一篇我们准备针对分布式事务问题,给出 分布式事务解决方案 。识别图中的二维码,我们在这里一起成长。 微服务分布式事务解决方案实战(解决方案篇)