分布式事务

分布式事务

在微服务系统中，每个微服务应用都可能会有自己的数据库，它们首先需要控制自己的本地事务。

一项业务操作可能会调用执行多个微服务。如何保证多个服务执行的多个数据库的操作整体成功或整体失败？这就是分布式事务要解决的问题。
CAP 和 BASE 是对大规模互联网系统分布式实践的理论总结
CAP:
C:consistency一致性
A:Availability 可用性
P:partion Tolerance 分区容忍性

CAP 原则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability
（可用性）、Partition tolerance（分区容错性），三者不可得兼。它是分布式系统中最核心最
重要的理论。

分布式系统的 CAP 理论：理论首先把分布式系统中的三个特性进行了如下归纳：
⚫ 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同
于所有节点访问同一份最新的数据副本）
⚫ 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写
请求。（对数据更新具备高可用性）
⚫ 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能
在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A
之间做出选择。

CAP 理论就是说在分布式系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会
出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可
用性之间进行权衡，要么选择 CP 要么选择 AP，没有分布式系统能同时保证这三点。
在分布式系统中，由于网络原因出现子系统之间无法通信的情况，就会造成分区。一般分布式系统中必须容忍这种情况，那么就需要在A和C之间进行取舍。

在分布式事务中，

如果保证CP，就意味着要让所有子系统的数据操作要么全部成功，要么全部失败，不允许有不一致的情况发生。但是强一致性会造成性能下降。
如果保证AP，就意味着可以牺牲一定的一致性，允许在各个子系统中存在有的数据操作成功，有的数据操作失败的情况，只要通过后续处理，能够达到最终一致即可。

分布式事务方案

分布式事务有以下解决方案：
XA
TCC
Seata 框架 AT 事务
SAGA
可靠消息最终一致性
最大努力通知

分布式对关系型数据库的冲击

对于 web 网站来说，关系数据库的很多主要特性却往往无用武之地
⚫ 数据库事务一致性需求
很多 web 实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一
致性要求并不高。允许实现最终一致性。 ⚫ 数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于
很多 web 应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几
秒之后，我的订阅者才看到这条动态是完全可以接受的。如：MQ 消息队列机制，意义，可
以解决瞬时的高并发，消峰填谷作用。
⚫ 对复杂的 SQL 查询，特别是多表关联查询的需求
任何大数据量的 web 系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的
报表查询，特别是 SNS 类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。
往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL 的功能被极大的弱化
了。
SNS：全称 Social Networking Services，专指社交网络服务，包括了社交软件和社交网站。例
如：脸谱 facebook、腾讯 QQ、微信等。