分布式事务(1)-理论基础

 分布式事务(2)---强一致性分布式事务解决方案

分布式事务(3)---强一致性分布式事务Atomikos实战

分布式事务(4)---最终一致性方案之TCC

 

一、服务架构演进

1.单体应用

最初的所有业务全部融合在一起,我们最初接触到的一个java应用开发完成之后打成一个war包进行部署。

优点:

1)架构简单,所有项目模块部署在一起,对于小型项目来说方便维护

缺点:

1)所有模块耦合在一起,对于大型项目来说不易与开发和维护

2)耦合度过高,一旦一个模块出现问题,会导致整个项目不可用

3)无法针对某个具体的模块来提升性能

4)无法进行水平扩展

2.垂直应用:

为满足业务需求,将单体应用部署多份到不同服务器上。但是无法根据某个模块来进行优化和性能提升,比如有些模块属于CPU密集型的,有些属于IO密集型的。无法进行针对性的优化。垂直应用架构就是将单体应用拆分未及格互不相干的应用,来提升整个系统的性能。比如针对C端的部署成一个应用,管理后台部署成一个服务,C端一般流量大,这个时候只需要把C端的服务多部署几个节点,而管理后台访问量则不需要。

优点:

1)可以根据不同系统的访问情况进行针对性优化

2)能够实现水平扩展

3)各系统分担流量,解决并发量问题

4)子系统故障,不影响其他子系统运行,提高整体的容错率

缺点:

1)拆分后各系统相对独立,无法进行相互调用

2)难免存在重叠的业务,重复开发,增加维护成本

3.分布式应用

垂直应用越来越多,重复的的代码也会越来越多,这个时候就讲重复的业务抽离出来形成单独的服务,提供给其他业务某块调用。这个时候一般拆分成表现层和服务层,服务层负责处理业务逻辑,提供给表现层调用,表现层负责和前端进行交互。

优点:

1)重复代码抽离,提高代码复用

2)可以针对性的进行优化

缺点:

1)系统之间调用关系,依赖关系变得复杂

2)系统维护成本变高

4.SOA(面向服务)架构

分布式架构下,当服务部署越来越多的时候,服务之间的关系,调用越来越复杂,这个时候我们需要增加统一的调度中心,对所有服务进行管理。增加注册中心,解决各个服务之间的依赖和调用关系,使其自动注册与发现。这个时候服务的粒度任然比较粗。

缺点:

1)某个服务出现问题,可能造成服务不可用

2)增加测试、运维成本

5.微服务架构

微服务架构是在SOA基础上进一步的扩展和拆分。将一个大项目拆分成一个个小的可独立部署的微服务,每个服务有自己的数据库。

优点:

1)服务彻底拆分,各个服务独立打包部署,独立升级维护

2)每个服务复杂的业务清晰,利于后期扩展升级、维护

3)服务之间采用REST或者RPC协议通信

缺点:

1)开发成本高(对开发人员要求更高)

2)成本更高,每个服务都需要机器来部署

3)涉及各个服务的容错性问题

4)涉及数据一致性问题

5)涉及分布式事务问题

 

二、分布式事务场景

1.跨JVM进程

因为服务拆分之后,要完成一个完整业务流程就可能涉及到多个服务之间调用。

2.跨数据库实例

分库导致或者本身业务就是操作不同的库

3.多个服务访问单数据库

 

三、数据一致性解决方案

ACID特性:利用数据库事务的ACID(原子性、一致性、隔离性、持久性)特性。有些分布式事务解决方案其实最终也是要依赖数据库的此特性。比如阿里seata中的AT模式。还有DTP模型、2PC模型(两阶段提交)、3PC(三阶段提交)、TCC模型、可靠消息最终一致性模型、最大努力通知模型

 

四、分布式事务基本理论

分布式事务的两大基本理论:CAP理论和Base理论

CAPconsistency一致性、可用性availability、分区容错性partition tolerance

要满足一致性那么我们在各个节点之间同步数据的时候,需要对资源进行锁定等所有节点都同步完成之后再返回数据。防止在同步过程中应用程序从从节点读取到不一致的数据。

可用性所有请求都会被响应,不会存在响应超时或错误的情况。

分区容错,如果将系统部署在一个节点,那么当节点出现故障时,整个系统将不可用。

因此需要多个节点部署,一个节点挂掉,其他节点也能对外提供服务。分区容错时一个分布式系统必须具备的基础能力。

AP:放弃一致性,但是一般都会考虑最终一致性。允许多个节点在一定时间内数据存在差异,一定时间之后达到一致。比如eureka,节点之间同步数据是一个定时任务从其他节点去同步数据的,定时任务没有触发的这个时间内,节点之间的数据是不一致的。

CP放弃可用性。当系统对一致性要求比较高的时候使用。比如ZK,写入数据时需要保证过半的节点写入之后,leader才会提交结果并返回。以此来保证数据的一致性。

CA放弃分区容错性,此时系统不会进行分区,也不用考虑网络不通,节点挂掉等情况,严格来说此时的系统已经不是一个分布式系统了。

Base理论是对AP的一个扩展,它牺牲了强一致性来获得可用性。Basically Available(基本可用)Soft State(软状态)和Eventually Consistent(最终一致性)的缩写。

软状态比如订单中可以设计“支付中”,“退款中”这种中间状态,过一段时间之后变成“支付成功”“退款成功”。

 

后续:

强一致性分布式事务解决方案、最终一致性分布式事务解决方案

你可能感兴趣的:(分布式事务(1)-理论基础)