本地事务在分布式的问题:
因为在分布式服务中,难免一个接口中会有很多调用远程服务的情况,这个就非常容易出现问题,以下是一个详细的例子: 例如,你为了保证事物的一致性等要求,所以,你方法上只写了@Transactional,但你的业务中又需要调用其他微服务的方法(Feign),这时就容易出现问题了,当你的远程服务调用时因为一些缘故 , 可能时间过长,timeout挂了, 异常等等 ,挂了需要回滚事务时 , 就会出现问题 为什么呢?
这是因为已经执行的远程服务是不会回滚的, 这是分布式的一个特性,不同的微服务讲会有不同的数据库,所以这个数据库的回滚,肯定无法使得其他的数据库回滚 (这是使用的异常机制进行的事务回滚)
实际项目中的例子:
可能出错的原因:
1 . 远程服务假失败:
远程服务其实调用成功 ,由于网络故障等没有返回
导致错误: 订单回滚,库存却扣减
2 . 远程服务执行完成,后面的其他方法出现问题
导致错误:一致性的远程请求,坑定不能回滚
总结: 本地事务 ,再付不是系统中 ,只能控制住自己的回滚 , 控制不了其他事物的回滚
本地事务:
1、事务的基本性质
数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)
和持久性(Durabilily)，简称就是 ACID；
原子性：一系列的操作整体不可拆分，要么同时成功，要么同时失败
一致性：数据在事务的前后，业务整体一致。
例子:
转账。A:1000；B:1000； 转 200
事务成功; A：800 B：1200
隔离性：事务之间互相隔离。
持久性：一旦事务成功，数据一定会落盘在数据库。
在以往的单体应用中，我们多个业务操作使用同一条连接操作不同的数据表，一旦有异常，
我们可以很容易的整体回滚；
Business：我们具体的业务代码
Storage：库存业务代码；扣库存
Order：订单业务代码；保存订单
Account：账号业务代码；减账户余额
比如买东西业务，扣库存，下订单，账户扣款，是一个整体；必须同时成功或者失败
一个事务开始，代表以下的所有操作都在同一个连接里面；
2、事务的隔离级别 (MySQL的一些规范)
1 . READ UNCOMMITTED（读未提交）
该隔离级别的事务会读到其它未提交事务的数据，此现象也称之为脏读。
2 .READ COMMITTED（读提交）
一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重
复读问题，Oracle 和 SQL Server 的默认隔离级别。
3 . REPEATABLE READ（可重复读）
该隔离级别是 MySQL 默认的隔离级别，在同一个事务里，select 的结果是事务开始时时间
点的状态，因此，同样的 select 操作读到的结果会是一致的，但是，会有幻读现象。MySQL
的 InnoDB 引擎可以通过 next-key locks 机制（参考"行锁的算法"）来避免幻读。
4 SERIALIZABLE（序列化）
在该隔离级别下事务都是串行顺序执行的，MySQL 数据库的 InnoDB 引擎会给读操作隐式
加一把读共享锁，从而避免了脏读、不可重读复读和幻读问题。
3、事务的传播行为
1、PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务， 就加入该事务，该设置是最常用的设置。
2、PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当 前不存在事务，就以非事务执行。
3、PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果 当前不存在事务，就抛出异常。
4、PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。
5、PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当 前事务挂起。
6、PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
7、PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务， 则执行与 PROPAGATION_REQUIRED 类似的操作。
4、SpringBoot 事务关键点
1、事务的自动配置
TransactionAutoConfiguration
2、事务的坑
在同一个类里面，编写两个方法，内部调用的时候，会导致事务设置失效。原因是没有用到代理对象的缘故。
解决：
0）、导入 spring-boot-starter-aop 依赖
1）、@EnableTransactionManagement(proxyTargetClass = true)
2）、@EnableAspectJAutoProxy(exposeProxy=true)
3）、AopContext.currentProxy() 调用方法
好处是 , 即使没有创建接口,也可以创建动态代理
分布式事务:
1、为什么有分布式事务
分布式系统经常出现的异常
机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP 、存储数据丢失 ...
分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个
东西，特别是在微服务架构中，几乎可以说是无法避免。
2、CAP 定理与 BASE 理论
1 、 CAP 定理
CAP 原则又称 CAP 定理，指的是在一个分布式系统中
一致性（Consistency）：
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访
问同一份最新的数据副本）
可用性（Availability） :
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据
更新具备高可用性）
分区容错性（Partition ） :
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition ）。
分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务
器放在美国，这就是两个区，它们之间可能无法通信。
CAP 原则指的是，这三个要素最多只能同时实现两点， 不可能三者兼顾 。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。 CAP 定理告诉我们，
剩下的 C 和 A 无法同时做到。
分布式系统中实现一致性的 raft 算法、 paxos
http://thesecretlivesofdata.com/raft/
Raft算法
-
领导选举：在Raft算法中，如果一个节点没有在预定的时间内接收到任何来自领导者或候选者的心跳消息，它会从跟随者状态转变为候选者状态，并发起选举。每个候选者都会向其他节点发送请求投票（RequestVote）的消息，其中包含自己的任期号。其他节点（跟随者）如果未投票给其他候选者且认为候选者的任期号足够新，就会投票给该候选者并回应同意（VoteGranted）的消息。
-
日志复制：一旦一个候选者获得了超过半数节点的投票，它就成为领导者。然后，领导者开始接受客户端的请求并将它们添加到其本地的日志中。接着，领导者会将日志条目通过AppendEntries RPC（远程过程调用）广播给所有跟随者。跟随者必须响应确认，如果跟随者日志中的条目与领导者不匹配，领导者会要求跟随者删除冲突及之后的所有条目，并重新同步。
-
心跳机制：为了维持系统的活跃性和一致性，领导者定期向所有跟随者发送空的AppendEntries RPC（即心跳）。这不仅帮助检测跟随者是否仍然存活，还确保了跟随者日志与领导者保持同步。如果跟随者长时间未接收到任何消息，它将重新启动选举过程。
Paxos算法
-
准备阶段（Prepare）：类似于Raft的领导选举，但更侧重于提案编号的管理。一个提议者（相当于候选者）选择一个唯一的提案编号，向接受者（相当于跟随者）发送Prepare请求，询问他们当前的最高提案编号以及已接受的提案值。接受者收到Prepare请求后，如果其提案编号小于请求中的提案编号，它将回复其当前的提案信息。
-
接受阶段（Accept）：当提议者收到多数接受者的回复后，它会发送一个Accept请求，其中包含了最高的提案编号以及一个提案值。接受者只有在其提案编号大于等于请求中的提案编号时，才会接受这个提案，并将其存储为已接受的提案。
-
学习阶段（Learn）：最后，一个学习者（可以是任何进程）可以查询接受者以获取最新的已接受提案，从而了解全局的一致性状态。
在CAP的延伸上,我们做了BASE理论
BASE 理论
BASE 理论是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可以采用适当的采取弱一致性，即最终一致性。
BASE 是指
基本可用（Basically Available）
1基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、 功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系 统不可用。
2 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的 查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询 结果的响应时间增加到了 1~2 秒。
3功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性, 部分消费者可能会被引导到一个降级页面。
软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体 现。mysql replication 的异步复制也是一种体现。
最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
4 、强一致性、弱一致性、最终一致性
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一 致性 。如果能容忍后续的部分或者全部访问不到，则是 弱一致性 。如果经过一段时间后要求 能访问到更新后的数据，则是 最终一致性
3、分布式事务几种方案
1）、2PC 模式
数据库支持的 2PC 【 2 phase commit 二阶提交】，又叫做 XA Transactions 。MySQL 从 5.5 版本开始支持， SQL Server 2005 开始支持， Oracle 7 开始支持。 其中， XA 是一个两阶段提交协议，该协议分为以下两个阶段：
第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit) 此操作，并反映是否可以提交 .
第二阶段：事务协调器要求每个数据库提交数据。其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务 中的那部分信息
XA 协议比较简单，而且一旦商业数据库实现了 XA 协议，使用分布式事务的成本也比较
低。
XA 性能不理想 ，特别是在交易下单链路，往往并发量很高， XA 无法满足高并发场景
XA 目前在商业数据库支持的比较理想， 在 mysql 数据库中支持的不太理想 ， mysql 的
XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。
许多 nosql 也没有支持 XA ，这让 XA 的应用场景变得非常狭隘。
也有 3PC ，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间
未收到回应则做出相应处理）
2）、柔性事务-TCC 事务补偿型方案
刚性事务：遵循 ACID 原则，强一致性。
柔性事务：遵循 BASE 理论，最终一致性；
与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。
一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
二阶段 commit 行为：调用 自定义 的 commit 逻辑。
二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
3）、柔性事务-最大努力通知型方案
按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对 。这种
方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种
方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通
知次数后即不再通知。
案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对
账文件），支付宝的支付成功异步
4）、柔性事务-可靠消息+最终一致性方案（异步确保型）
实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只
记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确
认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。
防止消息丢失
