CAP准则
一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）
一致性：一个集群里，无论从哪台机器访问，数据都是一致的
可用性：在可用节点上，能够正常提供服务，一般指的不会出现大量超时，错误等问题
分区容错性：集群中的节点出现宕机，依然能够正常提供服务
注意：三个准则中只能选择其中两种！！！
冲突原因：
保证C：如果要保证C的话，那么必须要等这条命令的修改执行到了所有服务器上，主从上都有这个修改，那么就必须等主服务器进行了命令传播后，才能回复客户端
保证A：如果要保证A的话，那么一条命令的执行时间就必须在规定的范围内，不能太久，及时给客户端作出响应
保证P：如果要保证P的话，那么一个节点坏了的时候需要有从服务器及时替上
🌰：选择CA，不用P？
如果选择CA的话，说明我们要保证数据同步保持一致并且不会超时，我们只有一台服务器的时候可以直接本地执行完然后直接返回消息，每次访问都是
都是一致的，因为只有一台服务器不需要同步，但是如果要P的话，就要考虑集群节点坏的时候需要其他从服务器替上，那么进行修改的时候就需要同步到所有的从服务器再返回修改，只有等同步完所有的之后才能主服务器返回响应，但是这样就会超时AP之间有冲突
🌰：选择CP，不用A？
如果选择CP的话，说明我们可以给时间去同步所有的从服务器，去保证数据一致，但是相应的时间也会花很久，那么我们就无法保证A
🌰：选择AP，不用C？
如果选择AP的话，说明我们可以直接主服务器做了修改后就给客户端响应，然后去异步的命令传播给其他从服务器，但是有可能其中某些从服务器的包丢失，那么其他请求过来访问的时候就有可能出现数据不一致的情况
选取模型
最常用的话就是AP了，一般为了保证一直能够提供服务就要使用集群，P必须要保证，在C，A之中，A>C ，一般就会牺牲一致性，但是可以会用办法去保证最终一致
看使用场景，银行这种涉及💰方面的话，C就比较重要，然后保证A，可以丧失P，一时的故障没有问题
AKF原则
在企业设计架构的时候，考虑AKF原则，x轴考虑高可用，一个节点的数据需要做备份，越大代表备份越多，y轴代表将一个节点的数据细分成多个模块，想微服务将业务上细分成多个模块，还有一个z轴，代表当细分成了多个模块之后，一个模块的并发依然很大，还需要细分，那么就需要把一个模块的数据分成多台机器存储，但是需要知道数据存在了哪台服务器上，就需要算法计算在哪台机器
A模型：算法写在每个客户端这，如果需要修改算法，每个客户端都需要修改
B模型：找一个代理，每个客户端访问先经过一个代理，代理做计算，然后访问具体机器
C模型：服务器自身进行算法划分，redis的做法就是分了16384个槽，然后每台服务器各自占了其中一部分槽，如果key属于该槽，那么就由这条命令执行
raft
分布式一致性算法，一般用于主从服务器，主服务器挂掉之后如何选举
简单说一下实现，三个角色，leader（主） ， follower（从） ，candidate（参与投票的候选人）
每个节点都有一个定时器，每个节点的过期时间不一样，如果一个节点的定时器归零了，那么这个节点就会成为candidate，然后让其他节点给自己投票，出现多个的话就会同时要票，如果没有超超过半数就会重新选举，票是先到先得的，如果超过半数，那么就会成为新的leader节点，这只是在于leader节点挂了的话，才会出现定时器归零，如果leader没有挂掉，那么就会定期发送心跳包，follower节点接收到心跳包，会重新刷新定时器的时间，直到leader挂掉，才会出现定时器归零进行选举leader节点
查阅资料
https://baijiahao.baidu.com/s?id=1650890231453975345&wfr=spider&for=pc
https://blog.csdn.net/qq_34802511/article/details/81296190
AKF：https://www.bilibili.com/video/BV1LA411e7Rv?p=7
Raft：https://blog.csdn.net/bjweimengshu/article/details/80222416
