CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾
一致性
一致性指的是分布式系统完成某个写操作时,服务器的各个都应该获取到最新的值,保持各个节点之前的数据一致性
可用性
可用性指的是在分布式系统中,用户可以永远在正常时间内进行读和写操作,一直可以正常访问并得到响应
分区容错性
分区容错性是指,在分布式系统中,其中一个节点宕机,整个系统还是能满足一致性和可用性的服务,就是说部分故障不影响整体使用,所以在项目架构时都会考虑一些外部因素造成的故障,都是要求部分故障不影响整体使用的
CP:优先保证一致性和分区容错性,在数据一致性要求比较高的场合使用,在出现问题时牺牲用户体验,恢复之后用户正常访问
AP:优先保证可用性和分区容错性,其中一个节点出问题之后还是能正常访问,不会影响用户体验,但是可能接收到的数据不是最新的数据,恢复之后数据变一致
eureka和zookeeper的服务治理使用了cap原则
eureka宁可接受故障实例,也不愿意丢掉健康的实例,zookeeper则比较严格,对于故障实例会直接剔除。
Eureka的服务治理强调了CAP原则中的AP,(即可用性和分区容忍性)。它与Zookeeper这一类强调CP(一致性,分区容忍性)的服务治理框架最大的区别在于:Eureka为了实现更高的服务可用性,牺牲了一定的一致性,极端情况下它宁愿接收故障实例也不愿丢掉健康实例,正如我们上面所说的自我保护机制。
zookeeper保证的就是CP
zookeeper不能保证每次请求的可用性,如果其中一个节点宕机或者在和另外一个节点同步数据的时候网络发生问题,请求就会出问题,会等恢复正常数据同步之后才会继续可以访问
eureka保证的是AP
在其中一个节点出问题时,其他节点可以正常访问,只不过可能数据不是最新数据,eureka还有自我保护机制,在运行期间统计心跳失败的比例,在15分钟之内是否小于85%,如果低于的话就会将这些实例保护起来,不会注销此项服务
对于eureka来说,它还有一个自我保护机制,在网络不好的时候,我们的服务可能不能及时去和eureka续约。我们的eureka会判断最近15分钟心跳失败的 比例是不是超过85%,如果超过,eureka会认为可能出现了特殊情况(例如网络波动),那么他会把这些失效的实例保护起来,而不会去剔除。