分布式事务

蓦山溪竹

已于 2023-03-04 14:29:43 修改

阅读量57

点赞数

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

于 2023-03-01 22:44:49 首次发布

本文链接：https://blog.csdn.net/qq_32388061/article/details/129291027

版权

分布式专栏收录该内容

1 篇文章 0 订阅

订阅专栏

场景：分布式系统经常会出现机器宕机、网络异常、消息乱序、数据错误、不可靠的TCP、存储数据丢失，为了解决这些问题，需要使用分布式事务

一、知识点

CAP定理

C :一致性(Consistency)

在分布式系统中的所有数据备份，在同一时刻拥有相同的值

A :可用性(Availability)

在集群中一部分节点发生故障之后，集群整体是否还能被访问到（对于数据读写具有高可用性）

P :分区容错性(Partition tolerance)

大多数分布式系统都分布在多个子网络。每个子网络叫做一个区(partition)。分区容错的意思是，区间通信可能失败。比如一台服务器放在中国，另一台放在美国，如果他们中的线路断了，就可能无法通信。

CAP这三个要素最多只能同时实现两点，P是总是成立的的，因此只能CP、或者AP

分布式系统中实现一致性的raft算法:
http://thesecretlivesofdata.com/raft/

对于大多数互联网应用的场景，主机众多、部署分散，而且现在集群的规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.9999%，即保障A和P，舍弃C

BASE 理论

BASE是指

基本可用(Basically Available)

基本可用是指分布式系统出现故障的时候，允许损失部分可用性(例如响应时间、功能上的可用性)，损失部分可用性不代表系统不可用
1、响应时间上的损失：正常情况下，搜索引擎只需要0.5s给用户返回查询结果，但由于出现故障，查询的结果响应时间慢了1-2秒
2、功能上的损失：购物网站在高峰期，为了保证系统稳定性，部分用户可能被引导到一个降级页面（错误页面），例如"当前访问人数过多，请稍后重试"

软状态(soft state)

软状态是指运行系统中存在中间状态，而该中间状态不会影响系统的整体可用性，分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态

最终一致性(Eventual Consistency)

最终一致是指系统中的所有数据副本经过一定时间后，最终能达到一致的状态，弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况

解决方案

1、2PC模式

2PC模式
注：下面所说数据库也可以理解为每个服务中的事务

第一阶段

事务管理器要求每个涉及事务的数据库预提交(precommit)此操作，并反映是否可以提交

第二阶段

事务管理器要求每个数据库提交数据

在2PC模式中，任意一个数据库否决本次提交，那么所有数据库都会被要求回滚他们在此事务中的那部分信息

除了2阶提交协议，还有3阶提交协议，不做详细描述

2、柔性事务-TCC事务补偿型方案

刚性事务：遵循ACID原则，强一致性
柔性事务：遵循BASE原理，最终一致性

与刚性事务不同，柔性事务允许同一时间，不同节点的数据不一致，但要求最终一致。

柔性事务

一阶段 prepare行为：调用自定义的prepare逻辑（也就是准备数据，执行相关业务操作，但是不提交）
二阶段 commit行为：调用自定义的commit逻辑（也就是提交数据）
三阶段 rollback行为：调用自定义的rollback逻辑（也就是回滚数据，回滚之前新增/修改的数据）
所谓的TCC模式，就是把执行、提交、回滚拆成三个操作，加入到全局事务中

3、柔性事务-最大努力通知型方案

按照规律进行通知，不保证数据一定能够通知成功，提供一个查询接口进行核对。这种方案主要用于和第三方通讯时，比如，调用微信或者支付宝支付成功后，支付宝/微信进行支付结果回调通知。这种方案也可以结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知数，通知后调用查询接口进行核对，核对成功则不继续通知，核对失败则继续通知，一直达到最大通知数。