你必须要知道的微服务--------微服务事务：2PC 3PC TCC Saga

什么是事务呢？

PS:在一个系统中，一组操作的集合就是事务；

 

说到事务，相信小伙伴们最熟悉的就是数据库的事务把那我们就先来看看数据的事务

数据库事务：在一个数据库系统中，一组SQL的集合就是事务    目的：数据库事务-------------》保证数据库数据的一致性；

何为数据库的数据一致性：非黑即白

为了保证数据库的一致性：三大特性

隔离性:操作与操作之间互不影响；

原子性：保证数据 只在最终和最开始两个状态；

持久性：更新到数据库；

当然 以上只对 单机的数据库系统有效：---------------------------------------当你的系统升级为分布式时 ，分布式事务就是用来解决跨库事务问题

分布式事务

在一个分布式系统中 ，一组服务的集合,就是分布式事务.

 

 

 例：当你要对成员进行操作时 同时要对以上两个服务就行操作：其中一个服务出现异常时，当操作结束后查询发现数据发生异常：也就是错误状态 1 0 团队微服务 1 成员微服务 0    那如何解决微服务中 操作的一致性呢？1 0 ------》 11/00

 

2.1   2PC(2阶段提交) 预提交阶段 与提交阶段

 

 理解角色：协调器 参与者

参与者：被调用者

协调器;客户端的第一层入口

 

 

 当客户端发起 对团队 和成员的操作;首先会对数据库进行本地提交（事务日志文件）当预提交之后 参与者会会发是否提交成功信息；如果都是成功才能进入第二阶段（发起commit命令 事务日志文件同步到本地和数据库）

如果有一方失败或者双方都失败 协调器将不会发生commit命令 则是发送Roolback命令（将undo命令全部删除）

2PC 存在的一些问题：（参与者 协调器 一直处于长连接状态  协调啊和参与者都是单体）

在2PC中 ：如果协调器宕机 或者参与者也宕机：-------------》发生阻塞 参与者一直等待协调器 一直等待 当前数据库被加锁

阻塞问题： 数据库阻塞，协调器阻塞 参与者阻塞

3PC （3阶段提交:）

 3PC 会主动检查数据是否正常 如果正常才会 做预提交 保证数据的一致性，并添加超时处理，解决阻塞问题

如果协调器等待参与者超时：就会发起回滚操作，终止事务；

如果参与者等待协调器超时：就会发起事务提交操作，达到持久的机制；

3PC存在的问题 也是数据不一致

1.参与者超时，如果执行了预提交，会出现数据不一致

2.协调器发送给微服务成功，发送给另一个失败

我们可以暂时总结一些2PC 3PC的特点：

2PC 3PC的定位 大家可以总结一下 ：时时刻刻都要保证数据的一致性；=====》但是 又会有很多问题无法让其保证

2PC 3PC如果想要保证数据一致性 的必要的两个条件： 

1.网络永远可以联通。

2.参与者与协调者永远不会宕机；

而着两个我们无法控制；-----------------只能顺势而为（为了保证网络可靠 协调者 参与者可靠 只能牺牲 数据一致性）

3.TCC 2阶段补偿型事务  （只需要最后保证数据一致）

 

 

 

Try

 

Try阶段:首先会直接跟新数据库 并标识数据库为更新状态 为0 此状态 数据不能使用 如果说两个Try都成功 才能进入第二阶段 若失败 中止

 

 

commit 

 

 

 如果Try都Ok 进入Commit业务操作;修改Try的状态改为1 如果失败 Tcc事务协调器将所有事务 全部回滚 1--》0 

 

cancel

 

 

 失败后 有TCC事务协调器 全部取消删除 回滚

客户端添加操作=====》Try 到数据库 修改状态0-》1 全部返回Ok ---》进入Commit 1-》0

TCC的（脏数据）

原因：团队数据库和成员数据库 Try成功但是Commit失败 

目的：不锁库 （释放线程资源）性能提升；

场景：数据一致性要求不强的场景;(WX朋友圈 微博博客)

Tcc的缺点：

1.业务复杂性变大，维护量表达，一个数据交互 涉及三次数据库操作

2.性能瓶颈;事务协调器必须等待所有的微服务(参与者)执行了所有的Try并且都成功后才能发送Commit命令 每个团队微服务都在 等待; 如果一直等待 各个微服务的响应  会导致TCC性能管理器的性能下降;在高并发场景下 是一个很大的性能瓶颈

下来就来介绍 终极解决办法------------------------------------------Sage 兵来将到水来土掩  数据库操作减少  不等待；

4.Saga---    中心思想：所有的事务都是独立的 

 

 

 

 阶段1 客户端 添加操作 --------直接 操作数据库 如果某一个操作失败  开始回滚

 

 

 

 其中任何一个返回失败 Saga会给每一个发送取消操作 以执行的操作 将被回滚 已添加的数据将被删除

Saga的优点;

没有任何的阻塞  因为各个服务都是独立的

 

Saga的缺点

任然存在数据不一致，但是最终会一致

PS：如何保证最终一致性：        1.事务日志 2.定时器（重试机制）

如果两个参与者 其中一个成功 一个失败  只会让成功的发起回滚 当前错误的服务不会发起回滚

发起回滚的次数 n-1次 不会对当前服务发生回滚操作。因为Saga协调器不会靠等待机制实现一致 当前服务只能靠直接事务自己进行回滚操作

总结 ：

微服务系统不是个2PC 3PC

微服务系统只能适合TCC /Saga 能保证高并发 高可用

2pc 3pc 适用的场景：一个微服务下 涉及到 分库分表操作