CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
一致性
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
AP原则的Eureka
Eureka保证了可用性，实现最终一致性。
Eureka采用的是集群方式，当多台服务器相互注册就形成了高可用，这样当其中的一台停止提供服务时，剩余的则会继续提供服务。
因为Eureka在集群部署时，多个实例相互注册和发现。Eureka架构有两个角色，即Eureka Server和Eureka Client。
Eureka Client通过向Eureka Server发送心跳（每30秒一次）来续约服务。如果某个客户端不能持续续约，那么Eureka Server断定该客户端不可用，该不可用的客户端将在大约90秒后从Eureka Server服务注册列表删除。服务注册列表信息和服务续约信息都会被复制到集群中的每个Eureka Server节点。来自任何区域的Eureka Client都可以获取整个系统的服务注册列表信息。
也就是Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性。
CP原则的Zookeeper
Zookeeper保证了强一致性，但是在集群模式不保证可用性。
Zookeeper集群模式角色
Zookeeper 集群通常是用来对用户的分布式应用程序提供协调服务的，为了保证数据的一致性，对 Zookeeper 集群进行了这样三种角色划分：Leader、Follower、Observer
- leader：负责进行投票的发起和决议，更新系统状态。
- follower：用于接收客户端请求并向客户端返回结果以及在选举过程中参与投票。
- observer：也可以接收客户端连接，将写请求转发给leader节点，但是不参与投票过程，只同步leader的状态。通常对查询操作做负载。
Zookeeper一致性协议:ZAB协议
Zab协议 的全称是 Zookeeper Atomic Broadcast。
Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。
ZAB协议特性
- ZAB协议需要确保那些已经在 Leader服务器上提交的事务最终被所有的服务器提交。
- ZAB协议需要确保丢弃那些只在 Leader上被提出而没有被提交的事务。
意思就是所有的客户端写请求，都要经过Leader服务器，然后通过Leader服务器广播给其他Follower服务器。
ZAB协议原理
ZAB协议要求每个Leader都要经历三个阶段：发现，同步，广播。
- 发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。（发现Follower服务器）
- 同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。（同步Leader服务器给Follower服务器）
- 广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。（将事务提交广播给Follower服务器）
ZAB协议实现数据一致性
如果Leader节点挂了，那么就要进行数据恢复，这个时候，就需要进行Zookeeper的Leader服务器选举
选举的Follower服务器需要有以下要求
- 新选举出来的 Leader 不能包含未提交的 Proposal 。
新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点。 - 新选举的 Leader 节点中含有最大的 zxid（事务ID） 。
这样做的好处是可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作。
Zookeeper通过ZAB协议保证了CP原则，即数据高一致性。
Zookeeper不能保证可用性的原因
- 不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性。
- 进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。
评论区