CAP 定理
- 一致性（Consistency） 在分布式系统中的所有数据备份，在同一时刻是否同样的值（等同于所有节点访问同一份最新数据副本）
- 可用性（Availability） 在集群一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）
- 分区容错性（Partition Tolerance） 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区。分区容错的意思是，区间通信可能失败，需要容忍错误。
CAP原则即为 以上三要素只能同时实现两点，不能三者兼顾，对于多数大型互联网的应用场景，主机众多，部署分散，而现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.99…% 即保证AP，舍弃C永远要满足分区容错
- AP（Eureka、Nacos）
- CP（Zookeeper、Consul）
raft算法实现一致性
http://thesecretlivesofdata.com/raft/
- 所有节点有三种状态、
跟随者、候选者、领导者 - 如果
跟随者不能感知到领导者，他将变成一个候选者，然后向其他跟随者请求投票给自己 - 其他
跟随者回应他们的投票 - 如果
候选者获得了超过半数的选票，他将变为领导者，以上这个过程为领导选举
- 系统的所有改变都需要通过
领导者 - 每一个改变都被当作一个
entry放入领导者节点日志，数据不会被更新，因为entry并没有被提交 - 提交
entry的第一步，是领导者先把其复制给其他跟随者，然后领导者待到大多数跟随者将entry写入后更新数据 - 然后
领导者通知跟随者entry已经提交，至此，集群完成了一致性操作。以上这个过程为日志复制
领导选举
- 有两个时限限制设置控制领导选举
- 第一个是
选举时限，指的是跟随者等待变为候选者的时间，随机分布在150ms-300ms - 在
选举时限时间过去之后，一个跟随者变为候选者并开启了一个新的选举，首先他会自己投自己一票 - 然后发送投票请求给其他
跟随者投票，如果其他跟随者在这次选举中还没有投过票，就把票投给他，并且重置选举时限时间 - 一旦一个
候选者获得了大多数票数，他成为领导者 - 然后
领导者将增量条目发送给它的跟随者，这些消息在内部发送，并且在规定的心跳时间内，跟随者会响应每条增量条目 跟随者每次接受心跳都会重置选举时限时间- 在下一个
跟随者停止收到领导者的心跳，成为候选者之前，该次选举结果会持续 - 如果同时有两个候选者进行选举并且获得了相同票数，则会重新开启一轮
选举时限，产生新的候选者进行选举
日志复制
- 一旦
新领导被选举出来，需要复制所有的改变给其他跟随者，通过心跳机制完成增量复制 - 首先客户端把改变发给
领导者，领导者将改变放入日志，在下一次心跳的时候将改变发送给跟随者 entry被提交一旦大部分跟随者确认收货，然后响应客户端
分区容错
每个分区都会产生一个领导，最后根据选举代数高的作为最新领导。如果每个分区节点数量相同，选不出领导，直接响应客户端集群当前不可用
BASE理论
- 基本可用（basically available） 是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）需要注意的是，基本可用绝不等价于系统不可用
- 响应时间上的损失。 正常情况下，搜索引擎需要在0.5s内返回给用户相应的查询结果，但是由于故障，查询结果响应时间增加到2-3秒
- 功能上的损失 购物网站在购物高峰时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面
- 软状态（soft state） 指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据有多个副本，允许不同副本同步的延时就是 软状态的体现。MySQL replication的异步复制也是一种体现
- 最终一致性（eventual consistency） 指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况
分布式事务解决方案
2PC模式
数据库支持的2pc【2 phase commit 二阶提交】，又叫做 XA Transaction MYSQL从5.5版本开始支持，SQL server 2005开始支持，Oracle7开始支持 XA是一个两阶段提交协议，该协议分为以下两个阶段：
- 事务协调器要求每个涉及到事务的数据库预提交（precommit）此操作，并反映是否可以提交
- 事务协调器要求每个数据库提交数据 其中如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们在此事务中的那部分信息
2PC 是一个同步阻塞协议，第一阶段协调者会等待所有参与者响应才会进行下一步操作，第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。
第二阶段协调者的没有超时机制，只能不断重试！
协调者是一个单点，存在单点故障问题
- 协调者在发送准备命令之前挂了，等于事务还没开始
- 发送准备命令之后挂了，有些参与者等于都执行了处于事务资源锁定的状态。不仅事务执行不下去，还会因为锁定了一些公共资源而阻塞系统其它操作。
- 发送回滚事务命令之前挂了，事务执行不下去，且在第一阶段那些准备成功参与者都阻塞着。
- 发送回滚事务命令之后挂了，命令发出去了，很大的概率都会回滚成功，资源都会释放。但是如果出现网络分区问题，某些参与者将因为收不到命令而阻塞着。
- 发送提交事务命令之前挂了，所有参与者都阻塞着
- 发送提交事务命令之后挂了，命令发出去了，很大概率都会提交成功，然后释放资源，但是如果出现网络分区问题某些参与者将因为收不到命令而阻塞着。
新协调者的缺陷
每个参与者自身的状态只有自己和协调者知道，所以当老协调者和某些参与者一起挂掉之后，新协调者不知道这些挂掉的参与者之前的状态，也无法继续做决定，可能会出现数据不一致的情况。
特点：
- 2PC 是一种尽量保证强一致性的分布式事务
- 同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低
- 存在单点故障问题，在极端条件下存在数据不一致的风险。
- XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低
- 性能不理想，特别是在交易下单链路，并发量通常很高，XA无法满足高并发场景
- XA目前在商业数据库支持的比较理想，在MySQL数据库中支持的不太理想，MySQL的XA实现，没有记录prepare阶段的日志，主备切换导致主库与备库数据不一致
- 许多nosql也没有支持XA，这让XA的应用场景变得十分狭隘
3PC模式
3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段：CanCommit、PreCommit 和 DoCommit。
3pc准备阶段=了解参与者运行状况，是否可以参加事务，而不会直接执行事务
3PC预提交=2PC准备阶段
3PC提交=2PC提交
引入了超时机制，参与者就不会傻等了，如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。
然而超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了。
柔性事务-TCC 事务补偿型方案
- 刚性事务：遵循ACID，强一致性
- 柔性事务：遵循BASE，最终一致性 与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致
TCC 是业务层面的分布式事务
TCC 指的是Try - Confirm - Cancel。
- Try 指的是预留，即资源的预留和锁定，注意是预留。
- Confirm 指的是确认操作，这一步其实就是真正的执行了。
- Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。
一阶段：prepare行为，调用自定义的prepare逻辑
二阶段：commit行为，调用自定义的commit逻辑
三阶段：rollback行为，调用自定义的rollback逻辑 TCC支持把自定义的分支事务纳入全局事务的管理中
TCC 对业务的侵入较大和业务紧耦合，撤销和确认操作的执行可能需要重试，因此还需要保证操作的幂等。
柔性事务- 最大努力通知型方案
按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时。比如：调用微信或者支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现。例如：MQ发送http请求，设置最大通知次数，达到通知次数后不再通知。 案例：银行通知、商户通知等（各大交易平台间的商户通知：多次通知、查询校对、对账文件），支付宝支付成功异步回调
柔性事务- 可靠消息+最终一致性方案（异步确保型）
业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正地发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送，只有在得到确认发送指令后，实时消息服务才会真正发送
参考
转载：https://blog.csdn.net/Chill_Lyn/article/details/107895929