CAP理论/AP架构/CP架构

最近有时间研究分布式架构,因为公司使用的Zookeeper,并没有使用Spring Cloud Eureka,所以想探究一下他们之间的区别,于是看到简书里的文章:Spring Cloud Eureka简介及与Zookeeper对比,明显的区别可能就是Zookeeper为CP设计,而Eureka为AP设计,但是对CAP/AP/CP很不理解,于是查阅资料,做一个简单的了解。

Eureka服务治理机制与Dubbo服务治理机制的比较

Feature Eureka Zookeeper
服务健康检查 可配支持 (弱)长连接 keepalive
CAP AP CP
watch支持(客户端观察到服务提供者变化) 支持 long polling/大部分增量 支持
自我保护 支持 -
客户端缓存 支持 -
自身集群的监控 支持 -

Eureka支持健康检查,自我保护等
Zookeeper为CP设计,Eureka为AP设计。作为服务发现产品,可用性优先级较高,一致性的特点并不重要,宁可返回错误的数据,也比不反回结果要好得多。
服务列表变更Zookeeper服务端会有通知,Eureka则通过长轮询来实现,Eureka未来会实现watch机制

CAP理论提出就是针对分布式数据库环境的,所以,P这个属性是必须具备的。
P就是在分布式环境中,由于网络的问题可能导致某个节点和其它节点失去联系,这时候就形成了P(partition),也就是由于网络问题,将系统的成员隔离成了2个区域,互相无法知道对方的状态,这在分布式环境下是非常常见的。
因为P是必须的,那么我们需要选择的就是A和C。
大家知道,在分布式环境下,为了保证系统可用性,通常都采取了复制的方式,避免一个节点损坏,导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况,而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的,所以,当P发生时,也就是无法向某个节点复制数据时,这时候你有两个选择:
选择可用性 A(Availability),此时,那个失去联系的节点依然可以向系统提供服务,不过它的数据就不能保证是同步的了(失去了C属性)。
选择一致性C(Consistency),为了保证数据库的一致性,我们必须等待失去联系的节点恢复过来,在这个过程中,那个节点是不允许对外提供服务的,这时候系统处于不可用状态(失去了A属性)。

最常见的例子是读写分离,某个节点负责写入数据,然后将数据同步到其它节点,其它节点提供读取的服务,当两个节点出现通信问题时,你就面临着选择A(继续提供服务,但是数据不保证准确),C(用户处于等待状态,一直等到数据同步完成)。

上一篇:Swin Transformer: Hierarchical Vision Transformer using Shifted Windows


下一篇:5、小型企业无线网部署(案例1)从客户需求来分析、规划、部署