1.分布式-理论

最新推荐文章于 2024-05-22 19:19:30 发布

os_lee

最新推荐文章于 2024-05-22 19:19:30 发布

阅读量1k

点赞数 24

分类专栏：分布式文章标签：分布式

本文链接：https://blog.csdn.net/qq_22321199/article/details/138703055

版权

分布式专栏收录该内容

3 篇文章 0 订阅

订阅专栏

3.分区容错性(Partition tolrance)

三、BASE理论

1.Basically Available(基本可用)

2.Soft state（软状态）

3.Eventually consistent（最终一致性）

3.TCC（Try-Confirm-Cancel）

一、什么是分布式系统

一个系统各组件分别部署在不同服务器，彼此通过网络通信和协调的系统。

可以指多个不同组件分布在网络上互相协作，比如说电商网站
也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余，当数据修改时也需要通信来复制数据

分布式最早出现的目地首先是解决单点问题，避免单点故障，然后解决了性能问题。

二、CAP理论

CAP理论说的是在一个分布式计算机系统中，一致性，可用性和分区容错性这三种保证无法同时得到满足，最多满足两个。

1.一致性Consisency

一致性指"all nodes see the same data at the same time"，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

2.可用性(Availability)

可用性指"Reads and writes always succeed"，即服务一直可用，而且是正常响应时间。

对于可用性的衡量标准如下：

3.分区容错性(Partition tolrance)

分区容错性指"the system continues to operate despite arbitrary message l
ss or failure of part of the system"，即分布式系统在遇到某节点或网络分区故障的
时候，仍然能够对外提供服务。分区容忍性分是布式系统具备的基本能力。

三、BASE理论

BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。

两个对冲理念：ACID和BASE

ACID是传统数据库常用的设计理念，追求强一致性模型。
BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

1.Basically Available(基本可用)

基本可用本质是一种妥协，也就是出现节点故障或者系统过载时，通过牺牲非核心
功能的可用性，保障核心功能的稳定运行。

实现基本可用的几个策略：

流量削峰
延迟响应，异步处理
体验降级
过载保护熔断/限流
故障隔离

2.Soft state（软状态）

弱状态允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。

原子性是硬状态，要求多个节点的数据副本都是一致的。

3.Eventually consistent（最终一致性）

分布式系统不能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据
一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制
方案设计等等因素。

四、什么是分布式事务

分布式事务是相对本地事务而言的，对于本地事务，利用数据库本身的事务机制，
就可以保证事务的ACID特性

1.本地事务ACID

ATOMICITY

原子性：一个事务中所有操作必须全部完成,要么全部不完成；

CONSISTENCY

一致性：在事务开始或结束时，数据库应该在一致状态；

ISOATION

隔离性：事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知；

DURABILITY

持久性：一旦事务完成，就不能返回，事务对数据所做的变更完全保存在数据库中；

2.分布式事务

在分布式环境下，会涉及到多个数据库。分布式事务其实就是将对一个库事务的概念
扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。

分布式事务处理的关键是：

需要记录事务在任何节点所做的所有动作；
事务进行的所有操作要么全部提交，要么全部回滚；

五、分布式事务解决方案

1.二阶段提交2PC

这是最传统的分布式事务协议。它分为两个阶段：准备阶段和提交阶段。在准备阶段，事务协调者询问所有参与节点是否准备好提交事务；如果所有节点都回复“准备好”，则进入提交阶段，协调者命令所有节点提交事务；如果有任何节点无法准备，协调者命令所有节点回滚。

2PC缺点：

1.性能阻塞问题

执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景

2.可靠性问题

2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3.数据一致性问题

在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

4.二阶段无法解决的问题

协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

2.三阶段提交3PC

3PC，三阶段提交协议，是二阶段提交协议的改进版本。三阶段提交有两个改动点：

在协调者和参与者中都引入超时机制
为了解决2PC中协调者单点故障的问题，3PC引入了预提交阶段

所以3PC分为3个阶段：CanCommit 准备阶段、PreCommit 预提交阶段、DoCommit 提交阶段

3PC缺点

与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者和参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。但数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

2PC和3PC都无法保证数据绝对的一致性，一般为了预防这种问题，可以添加一个报警，比如监控到事务异常的时候，通过脚本自动补偿差异的信息。

3.TCC（Try-Confirm-Cancel）

TCC模型将事务操作分为三个阶段：Try（预留资源）、Confirm（确认提交）和Cancel（取消释放）。在Try阶段，每个参与者尝试预留资源但不实际提交，如果所有参与者都能预留成功，则在Confirm阶段真正提交事务；否则，在Cancel阶段撤销之前的操作。

4.Saga

Saga通过一系列的短事务（也称为子事务）来模拟长事务，每个子事务都是可补偿的。如果某个子事务失败，Saga会执行之前所有子事务的补偿操作，从而达到事务的最终一致状态。

5.基于消息的最终一致性:

在这种模式下，服务之间通过消息队列异步通信，利用消息的发送与确认机制保证最终一致性。通常包括发布/订阅模型和事件驱动架构，如 Saga 也可以通过这种方式实现。

6.最大努力通知

最大努力通知也称为定期校对，是对MQ事务方案的进一步优化。它在事务主动方增加了消息校对的接口，如果事务被动方没有接收到主动方发送的消息，此时可以调用事务主动方提供的消息校对的接口主动获取。

最大努力通知，事务主动方尽最大努力（重试，轮询....）将事务发送给事务接收。被动方也可调用接口校对并消费。