分布式事务（典型的分布式事务场景+CAP+解决方案）

分布式事务与分布式锁的区别：

分布式锁解决的是分布式资源抢占的问题；分布式事务和本地事务是解决流程化提交问题。

SQL中的4个事务隔离级别：（1）读未提交（2）读已提交（3）可重复读（4）串行化

MySQL的本地事务实现方案

操作单一的数据库，这种情况下的事务称之为本地事务(Local Transaction)。
通过 日志和锁、事务隔离级别 来保证的事务的 ACID特性。详见我的这篇并发性事务带来的问题+并发控制(MySQL事务隔离级别、MySQL 锁)

多个事务并发操作时，数据库中会出现三种问题：脏读，幻读，不可重复读。

分布式事务的基本概念

保证分布式系统中的数据一致性，保证数据在子系统中始终保持一致。分布式系统中操作要么一起成功，要么一起失败，必须是一个整体性的事务。
简单的说，在分布式系统上一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

当本地事务要扩展到分布式时，它的复杂性进一步增加了。

1.存储端的多样性。
首先就是存储端的多样性。本地事务的情况下，所有数据都会落到同一个DB中，但是，在分布式的情况下，就会出现数据可能要落到多个DB，或者还会落到Redis，落到MQ等中。
2.事务链路的延展性
本地事务的情况下，通常所有事务相关的业务操作，会被我们封装到一个Service方法中。而在分布式的情况下，请求链路被延展，拉长，一个操作会被拆分成多个服务，它们呈现线状或网状，依靠网络通信构建成一个整体。在这种情况下，事务无疑变得更复杂。

一般情况下，在分布式下，事务会被拆分解决，并根据不同的情况，采用不同的解决方案。

典型的分布式事务场景：

跨库事务
个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。
分库分表
通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。
对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。

如，对于sql：insert into user(id,name) values (1,"tianshouzhi"),(2,"wangxiaoxiao")。这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。
但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

微服务化
将复杂业务拆分成不同的独立服务，以简化业务逻辑。拆分后，独立服务之间通过RPC框架来进行远程调用，实现彼此的通信。下图演示了一个3个服务之间彼此调用的架构，典型分布式事务场景：

数据一致性和高性能，是天生的矛盾

分布式事务实现方案必须要考虑性能的问题，如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。

CAP定理

WEB服务无法同时满足一下3个属性：

一致性(Consistency) ：客户端知道一系列的操作都会同时发生(生效)。
可用性(Availability) ：每个操作都必须以可预期的响应结束。
分区容错性(Partition tolerance) ：即使出现单个组件无法可用，操作依然可以完成。

具体地讲在分布式系统中，一个Web应用至多只能同时支持上面的两个属性。因此，设计人员必须在一致性与可用性之间做出选择。

权衡：
C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。
还有一种是保证 CP，舍弃 A。例如网络故障是只读不写。

CAP和ACID中的A和C区别

（1）A的区别：

ACID中的A指的是原子性(Atomicity)，是指事务被视为一个不可分割的最小工作单元，事务中的所有操作要么全部提交成功，要么全部失败回滚；
CAP中的A指的是可用性(Availability)，是指集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求；
（2）C的区别：
ACID一致性是事务执行前后，数据库完整性；
CAP的一致性是分布式节点的数据的一致性。

分布式事务了解吗？你们是如何解决分布式事务问题的？

这篇博客超详细分布式事务详解

Seata AT模式和Seata TCC是在生产中最常用。

强一致性模型，Seata AT 强一致方案模式用于强一致主要用于核心模块，例如交易/订单等。
弱一致性模型。Seata TCC 弱一致方案一般用于边缘模块例如库存，通过TC的协调，保证最终一致性，也可以业务解耦。

（1）强一致性场景
电商交易交易中的库存和订单、优惠券），使用成熟的如中间件Seata AT模式。
Seata AT模式，保障强一致性，支持跨多个库修改数据；

订单库：增加订单
商品库：扣减库存
优惠券库：预扣优惠券

（2）弱一致性场景
对于数据一致性要求没有那些特别严格、或者由不同系统执行子事务的场景，可以回答使用Seata TCC 保障弱一致性方案

电商订单支付服务，更新订单状态，发送成功支付成功消息，只需要保障弱一致性即可。

（3）最终一致性场景
基于可靠消息的最终一致性，各个子事务可以较长时间内异步，但数据绝对不能丢的场景。可以使用异步确保型事务事。

可以使用基于MQ的异步确保型事务，比如电商平台的通知支付结果：
积分服务：增加积分
会计服务：生成会计记录

seata

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式。

Seata 分三大模块 :

TC ：事务协调者。负责我们的事务ID的生成，事务注册、提交、回滚等。
TM：事务发起者。定义事务的边界，负责告知 TC，分布式事务的开始，提交，回滚。
RM：资源管理者。管理每个分支事务的资源，每一个 RM 都会作为一个分支事务注册在 TC。

可靠消息最终一致性【RocketMQ 事务消息方案】----尚未学完

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成。
在这里插入图片描述
事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致**分布式事务问题。**因此可靠消息最终一致性方案要解决以下几个问题：
【1】本地事务与消息发送的原子性问题
【2】事务参与方接收消息的可靠性
【3】消息重复消费的问题