本地事务和分布式事务

1 本地事务ACID 和 CAP中的CA区别

    本地事务： A--》 原子性 一个事务中所有操作，要不全部完成，要不全部不完成，事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务没有被执行过一样。

                      C--> 一致性  事务的一致性指在一个事务执行之前和执行之后数据库都必须处于一致性状态，如果事务成功完成，那么系统中所有变化将正确应用。系统处于有效状态。如果在事务中出现错误，系统中所有变化都自动回滚，系统将返回到原始状态。

                    I--》 隔离性 指的是在并发环境中，当不同的事务同时操作相同的数据时，每个事务都有各自的完成数据空间。打个比方，你买东西，是不会影响到其他人的。

                    D：持久性 指的是只要事务成功结束，它对数据库所作的更新就必须永久保存下来。即使系统发生崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态

                   打个比方，买东西的时候需要记录在账本上，即使老板忘记了  也有据可查

分布式事务

     CAP定理 

            C -->一致性   对某个指定的客户端来说，读操作能返回最新的写操作，数据分布在不同节点上的数据来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果在某个节点没有读取到，就是分布式不一致。

         A --> 可用性 非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应。）可用性的两个关键是一个合理的时间，一个合理的响应。

合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的。

 

2.分布式事务常用的解决方案的优缺点是什么？ 适用于什么场景？

解决方案：

1.XA Transactions

2.TCC

3. 本地消息表

4.MQ事务

5.Saga事务

TODO   --- 完整优缺点及使用场景

 

 

缺点： 增加系统的复杂度和成本

3.分布式事务出现的原因？ 用来解决什么痛点？

分布式事务出现的两种原因：

Service产生多个节点 

     举个例子：  一个公司之内，用户的资产可能分为好多个部分，分为余额，积分，优惠券等等

，在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。这样就无法保证积分扣减之后，优惠券能否扣减成功。

Resource产生多个节点

   Mysql一般装千万级的数据就得进行分库分表

   对于一个支付宝的转账业务来说，你给朋友转钱，可能你的数据库在北京，而你朋友的钱存在上海，所以依然无法保证他们能同时成功

 

用来保证不同数据库的数据一致性