分布式事务（一）基础概念和理论

你好生活
110 阅读9分钟

「这是我参与11月更文挑战的第8天，活动详情查看：2021最后一次更文挑战」

基础概念

单机事务

单机事务主要特性(ACID)：

  • 原子性：原子性是指事务的操作都是原子的，操作要么全部成功，要么失败全部回滚；
  • 一致性：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态；
  • 隔离性：隔离性是指事务的操作之间是相互隔离的，互不干扰，多个事务并发执行时，就感觉像单一事务执行一样，达到预期结果；
  • 持久性：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作；

以上的事务特性，在业务上我们都是依赖数据库去实现的。

分布式事务

随着互联网的快速发展，软件系统由原来的单体应用转变为分布式应用。分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。

分布式事务产生的情景

  • 跨JVM进程产生分布式事务

典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。

  • 跨数据库实例产生分布式事务

单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。
再有就是分库分表也会存在分布式事务。

  • 多服务访问同一个数据库实例

订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

分布式事务基础理论

CAP

image.png

CAP理论是分布式系统的基石，CAP理论告诉我们，任何基于网络共享系统，最多只能满足一致性 (C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个要素中的两个要素。

1、一致性 (C:Consistency)

在分布式系统下，为了保证系统的高可用，数据是需要进行多分拷贝做数据备份(或者为了保证数据的数据的读写分离，同一数据需要分布在不同的系统中)。数据一致性是指在多个副本之间(或多份数据之间)是否能够保持一致性。在一致性的需求下，当一个系统在数据一致的情况下执行的更改操作后，应该保证系统的数据仍然处于一致的状态。

对于一个将副本数据分布在分布式不同节点上的系统来说，如果第一个节点对节点进行了更新，第二个节点缺没有完成更新操作，那么在第二个节点上的数据与第一个节点的数据就不一致，就可能导致在第二个节点上读取的数据不正确，这就是比较典型的分布式系统下数据不一致的场景。

2、可用性(A:Availability)

在分布式环境下，可用性是指系统提供的服务一直处于可用的状态，对于任何用户的请求，总是能够在一定的时间内做出响应，返回结果。这里需要重点说明“一定时间”与“返回结果”。

“一定时间”是指，对于用户的请求操作，系统必须能够快速响应结果，如果处理时间超出一定的范围，调用方可能自行断开连接，标识为服务不可用或服务响应变慢，导致业务受到影响，接口的性能指标比较直观的反应在tp99耗时，QPS/TPS上

“返回结果”是系统的可用性的重要指标，它要求系统在完成对用的请求处理后，能够按照接口定义，响应正确的结果。所有的影响结果能够明确地反应出对请求的处理结果，不管是成功或失败，都能够明确表示。

3、分区容错性 (P:Partition tolerance)

由于分布式系统是通过网络进行通信，网络是不可靠的，当出现任意的网络分区出现故障的时候，仍然能够保证服务对外提供一致性和可用性的服务。换句话说，分区容错是站在分布式系统的角度，对访问本系统的调用方的一种承诺。只要不出现整个网络环境的不可用，分布式系统都能保证提供服务。

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种

CA without P： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

CP without A： 如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C： 要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

注册中心 CP AP选择

eureka AP

eureka 保证了可用性，实现最终一致性。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性。

zookeeper CP

zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性。

谈谈注册中心 zookeeper 和 eureka中的CP和 AP 和 微服务：注册中心ZooKeeper、Eureka、Consul 、Nacos对比

BASE理论

BASE是指基本可用（Basically Available），软状态（Soft state）,最终一致性（Eventual Consistency），核心思想是即使无法做到强一致性（CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

1.基本可用

分布式系统故障时，允许损失部分可用性，即保证核心可用。

关键词是部分和核心，具体哪些业务可以损失，哪些业务必须保证，是一项有挑战的工作。以用户管理系统为例，登陆是核心功能，注册是非核心功能。因为未注册的用户本来就没有使用过系统的业务，注册不了最多就是损失一部分用户，而且这部分用户数量较少。如果用户已经注册但无法登陆，那就意味用户无法使用系统。

2.软状态

允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。

3.最终一致性

系统的所有数据副本经过一定时间后，最终能够达到一致性的状态。

BASE理论本质上是对CAP理论的延伸和补充，更具体的说，是对CAP中AP方案的一个补充。

本文已参与「新人创作礼」活动，一起开启掘金创作之路。

avatar
文章
阅读
粉丝