Java基础之《分布式事务（2）—什么是分布式事务》

一、本地事务和分布式事务

1、本地事务
本地事务是关系型数据库中，由一组SQL组成的一个执行单元
它有一个缺点：仅支持单库事务，并不支持跨库事务

2、分布式事务
是指一个企业需要同时操作多个数据库的情况下，而且必须保持ACID的特性。一般应用于微服务的多服务处理

在电商系统中，支付订单，就是一个分布式事务了
第一步：支付服务，修改支付订单状态
第二步：订单服务，订单状态修改为已支付
第三步：库存服务，减库存
第四步：积分服务，为该用户送积分
以上4个步骤，在分布式系统中，是一个整体，也就是一个分布式事务

该事务必须保证2点：
保证ACID特性
保证性能问题

二、分布式CAP定理
什么是分布式CAP定理

1、一致性（Consistency）
指数据的一致性，特指分布式系统中数据的一致性

2、可用性（Availability）
指服务的高可用，特指分布式系统中服务的高可用，某个服务瘫痪了不影响整个分布式系统的运行

3、分区容错性（Partition tolerance）
分区容错性：指网络故障，特指分布式系统中，服务之间出现了网络故障，整个分布式系统任然保持可用性和一致性

4、一句话概括
在分布式系统中，网络故障，服务瘫痪，整个系统仍然保持一致性

三、分布式CAP举例

1、张三有100元优惠券，在商城买了件衣服

2、3个问题
如何体现数据一致性？
如何体现可用性？
如何体现分区容错性？

四、什么是分区

1、在断网的情况下，2台系统变成了独立网络，各自访问不了，这种情况就是分区

在分区的情况下，如果要保持数据一致性和系统可靠性，那就是分区容错性了

五、CAP技术实现所面临的困惑

1、在分布式系统中，出现网络故障P，服务瘫痪A，整个系统的数据仍然保持一致性C（无法做到）

2、相对可以实现的方案
业界的做法是CAP，三选其二

当服务之间出现网络故障的情况下：
如何保证订单服务和卡券服务高可用？
一笔订单同时扣除100元优惠券如何实现？

3、AP
CAP牺牲一致性（AP）：保证高可用（保证订单服务可以正常访问，保证卡券服务可以正常访问，是牺牲了数据的一致性。）
张三下单成功，但是不扣除100元优惠券，这种情况下，张三下订单成功后再去查看100元，居然还在。
那怎么办呢？如何解决这种问题？
一般的做法是，当网络恢复正常的情况下，订单服务重试请求卡券服务，再扣除100元优惠券。

4、CP
CAP牺牲可靠性（CP）：保证数据一致性，即为了保证数据的强一致性，当张三来下订单的时候，提示“系统维护中”。等服务间的网络恢复正常后，张三再来下订单。

5、不要P，只留CA
不要P分区，即不允许网络出现故障，这是不可能实现的。
所以在分布式系统中，是不存在CA的。
即使单体系统也做不到CA，因为单体系统也会出现单一故障。

六、zookeeper的CAP定理
zookeeper选了CP

1、zookeeper是CP的原理，即保证了数据一致性，牺牲了可用性
zk的数据同步原理：
client1注册给了server1，server1同步给了server2，server2广播同步给各个follower，为了保证数据的一致性，只有这整个过程都成功了，client1才收到注册成功。

2、牺牲可用性说明

当leader重启或网络故障的情况下，整个zk就会重新选举leader，在选举期间，client是不能注册的，即zk不可用，所以牺牲了可用性。

3、zk重新选举后

只有等到整个系统选举成功后，系统才恢复注册，故zk为了保证数据一致性，牺牲了可靠性。
CP有一个致命的缺点，就是在大型分布式系统中，网络是非常复杂的，leader出现了故障的频率是非常高的，而且很容易引发雪崩。所以很多大型分布式系统都不选zk的原因。

七、eureka的CAP定理
eureka选了AP

1、eureka是AP原理，即保证可用性，牺牲了一致性
eureka的数据同步原理：
client1注册给了server1，server1直接告诉client成功。剩下的就是server1同步给server2，为了保证服务的可用性，他们都是异步同步的。

八、CAP定理常见面试题
如果你的简历有写dubbo或springcloud，那面试官一般就会问你CAP定理了。

1、请说说什么是分布式CAP定理？
2、一般还会细问什么是分区容错性？因为这个是CAP的核心。
3、zookeeper和eureka的CAP区别？
4、你们公司的分布式架构是怎么做的？哪些服务设计成了CP，哪些设计成了AP？

九、分布式BASE定理
先有CAP定理，再有BASE定理。

1、什么是BASE定理
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。
BASE理论是由eBay架构师提出的。
BASE定理是CAP中一致性和可用性的权衡结果，它来自于大规模互联网分布式系统的实践总结，是基于CAP定理逐步演化而来的。

2、BASE定理的核心思想
即使无法做到强一致性，但是每个应用可以根据自身的业务特点，采用合适的方法来达到最终一致性。

3、什么是基本可用
CAP中可用是高可用，BASE定理中可用是基本可用

（1）第一个概念：损失响应时间

例子：访问商品服务，如果是读取redis是10ms，如果redis瘫痪，响应时间变成了1-2秒

CAP可用性的服务响应时间可能是10ms，而BASE基本可用性的响应时间是1-2s，即允许损失部分可用性的（时间上的损失）。

（2）第二个概念：损失系统功能

例子：访问聚合服务，此时商品服务瘫痪了。采用服务降级来保证用户的体验性。服务降级，通过降级接口，返回一批热门的商品列表数据给用户。

BASE的基本可用性是允许某个服务出现故障时，采用了服务降级等手段保证用户的体验性，即允许损失部分系统功能。

4、什么是软状态

（1）什么是硬状态
指ACID的原子性。
例子：硬状态只有在订单改状态、积分发送成功、仓库出单成功，即3者同时成功的情况下，才算支付成功。

（2）什么是软状态
不用完全符合ACID的原子性。

例子：先把订单状态改成已支付成功，然后告诉用户已经支付成功了。剩下再异步发送MQ消息通知积分服务和仓库服务。即使消费失败，MQ消息也会重新发送（重试）。

5、什么是最终一致性

（1）什么是强一致性
指ACID的原子性，和硬状态一样

（2）什么是最终一致性

和强一致性相反，数据不用即时一致。如何实现最终一致性。一般是通过异步来实现，失败了就重试。在不影响用户体验的情况下，可以延时，即使失败了采用重试处理。 

例子：MQ第一次失败，重发第二次失败，会一直重试，直到成功