CAP理论

CAP理论

概述：

指的是在一个分布式系统中一致性(Consistency)、可用性(Avaiability)、分区容错性(Partition tolerance)，三者不能同时获取

• 一致性( C):在分布式的所有数据备份中，在同一时刻是否会有相同的值，就是所有的节点再同一时间的值需要完全一致，单节点越多数据同步越耗时

    举例：比如说现在有A,B,C三个银行对应A,B,C三个数据库，因为无论是什么银行卡都可以查看余额，所以我在A存钱，将数据插入到A库的同时，也应该同时插入到B,C库中，这就是在同一个节点同一时间(存钱)的数据是一致的
  

• 可用性( A)：当负载过大后，集群的整体是否还能够正常响应客户端的请求,

    举例：一个购买商品的功能，平常每天请求1000次左右，响应时间是10s左右并且客户的可接受的使劲按范围是10s - 20s，但是某一天，商家做活动，这一天的请求量是10000，那么这一天的请求时间是否在10 - 20s之间，是否在一个可接收的时间内，这就是可用性
  

• 分区容错性 ( P):就是高可用性，一个节点崩溃了，不会影响其他的节点，比如说一共100个节点，挂掉了几个，不会影响服务的正常使用

CAP理论是说在分布式系统中，最多只能实现两点，因为当前的网络硬件肯定会出现延迟丢包的问题，所以分区容错性必须要实现，所以我们只能在一致性和可用性中进行选择

为什么CAP只能够三选二

1. CA：既要保持数据的一致性[C]，也要保证数据在正常时间内响应[A]，那么就要减少服务器的数量，所有[P]不满足
2. CP：既要满足数据的一致性[C]，又要满足需要服务器数量多的情况，那么一致性会耗费大量时间，所以不能保证[A]
3. AP：既要满足数据在正常时间内响应[A]，也要满足大量服务器问题[P]，那么就不能够保证数据的一致性[C]，因为一致性需要耗费大量时间

注册中心的选择

Zookeeper：CP设计，可保证数据的一致性，在集群中，若某一个节点失效，那么会选择出一个leader，相当于选择出一个主节点，若半数一上的几点不能使用，那么就会无法提供服务
Eureka：AP设计，无主从节点，一个节点不能使用，可以使用别的节点

结论：

分布式设计中P肯定是要满足的，所以只有选择C和A
若需要满足一致性则选择Zookeeper，比如金融行业
若需要满足可用性则选择Eureka，如电商系统