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

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

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

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

MySQL的本地事务实现方案

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

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

分布式事务的基本概念

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

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

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

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

典型的分布式事务场景：

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

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

3. 微服务化
   将复杂业务拆分成不同的独立服务，以简化业务逻辑。拆分后，独立服务之间通过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。