自学内容网 自学内容网

Eureka、Nacos、Zookeeper、Redis等应用是AP还是CP?

理解CAP是什么?

  • C Consistency 一致性
    有集群cluster,如果有客户端对cluster进行了写操作,改变了cluster中的数据,则后面的客户端请求再次访问请求时,cluster返回给客户端的是最新的数据。
    也可以理解为cluster中,每个节点都保存了一份数据副本,当有客户端对集群进行了写操作,或者因为其他原因,集群的状态改变了,这些写操作或者状态的改变,必须同步到cluster中的每个节点,才能保证集群中每个节点的数据副本是一致的。

  • A Availability 可用性

  • P Partition Tolerance 分区容错性
    分布式环境中,部分节点因为网络原因彼此失联后,即与其他节点形成网络分区时,系统仍然能够正确地提供服务的能力。

AP和CP

业界已有理论证明,对于CAP,只能满足其中的两个,又因为在分布式环境中,我们使用分布式的方式构建系统,有一个非常重要的原因是提高可用性,所以P(分区容错性)是需要满足的,对于剩下的A和C,我们只能选择性地满足一个。

Eureka、Nacos、Zookeeper、Redis是CP和AP中的哪种应用?

这篇文章着重讨论业界的一些比较出名的应用都是CP和AP中的哪一种应用,比如注册中心Eureka、Nacos、Zookeeper,NoSql数据库Redis
先给出结论,后面再单独地对每种应用为什么是CP或者AP做出详细阐述,以及使用的分布式协议做简单讲解。

应用类型开发语言应用名字CP/AP分布式协议
注册中心JavaEurekaAP对等复制(Peer to Peer)
注册中心JavaNacosAPdistro(Nacos自定义的分布式一致性协议)客户端在向Nacos进行注册时,可以通过ephemeral选择AP模式
注册中心JavaNacosCP简化版raft客户端在向Nacos进行注册时,通过ephemeral=false来选择CP模式
注册中心GoConsulCPraft客户端在向Nacos进行注册时,通过ephemeral=false来选择CP模式
分布式协调组件、注册中心JavaZookeeperCPZAB
NoSqlCRedisAP主从异步同步数据写操作操作主节点,主节点将写操作异步同步到从节点

Eureka

Eureka是AP模式的应用,具有高可用性,客户端在任何时候,都可以向Eureka集群中的任何节点获取到服务列表,但不表征数据的强一致性,所以消费者可能会拿到过期的服务列表。
Eureka集群的节点之间,采用对等复制的方式来实现数据的同步,也就是说每个节点都可以对客户端的写请求进行响应,不存在写压力瓶颈。这种数据同步方式,叫做Peer to Peer,每个节点之间的关系是对等和公平的。

Zookeeper

作为注册中心时,是CP型的应用。使用ZAB协议来保证节点之间的数据的一致型。
ZAB是 Zookeeper Atomic Broadcast的缩写,叫做Zookeeper原子广播协议。
待对ZAB协议进行补充。

Nacos

Nacos做了兼容,服务在向Nacos进行注册时,可以选择注册成AP或者CP,可以通过ephemeral选型进行设置。

  • AP
    当表现为AP型的应用时,使用Nacos自己实现的Distro协议来实现节点之间的数据同步,并且每个节点都可以对客户端进行响应,这种协议的特点是Nacos cluster中的每个节点负责处理一部分客户端节点的注册,具体的客户端和cluster节点的对应关系,由集群中的前置filter节点决定,然后将写请求转发到对应的Distro节点,Distro节点处理完成后,会将该数据同步到其他Distro节点。
    当读请求到来时,加入是B节点处理读请求,由于每个节点理论上(注意是理论上)都缓存了全量数据,所以会直接将本地数据返回给客户端。但是之前有一次请求是A处理的,但是A节点的数据还没有到达B节点,这时候B节点返回给客户端的数据就是过期数据。
    通过上述例子,我们可以感受到AP模式,写并发很高,因为每个节点都可以处理请求,读响应也很快,但是有可能会让客户端获取到过期数据。
  • CP
    当表现为CP模式时,使用的是简化版的Raft协议在集群之间进行数据同步。
    Raft协议中,集群中的节点表现为以下三种角色中的一种:
    – Leader:负责Client交付和log复制,同一时刻中,集群中最多存在1个。
    – Follower:被动响应请求RPC,从不主动发起请求RPC(RPC概念后面补充)。
    – Candidate:一种临时的角色,只存在于leader的选举阶段,某个节点想要变成leader,就需要leader主动发起投票请求,同时将自己的状态从fallower转变为Candidate。如果选举通过,则自己变成leader。如果其他节点成为leader,则当前节点变位Follower。

在选举过程中,在同一个term中(一个任期内),按照先到先得,且只会投票给一个候选人,且候选人的log至少需要和自己一样新。
选举出loader之后,由leader处理客户端的写请求。当leader收到客户端的写请求后,通过heatbeat将该Entry同步给其他Follower,Folower收到日志后记录日志,然后想Leader发送ACK,当Leader收到半数以上的Follower的ACK消息后,就会通知所有Follower将该日志存储到自己的磁盘。
从上述过程中可以看到,CP型的Nacos的Leader选举过程非常中,需要选举出leader,由leader处理客户端的写请求,客户端的写请求操作都几乎需要集群中的所有节点响应后,才能返回给客户端,响应速度比AP模式慢。写请求都要经过leader,leader是写并发能力的瓶颈。
可以看出,CP模式在保持数据的强一致性的同时,牺牲了响应速度和写并发能力。

Redis哨兵和Redis集群

我的理解是AP,因为Redis哨兵的主从之间和Redis集群中的主从之间,采用的是异步复制数据的方式,当客户端对主节点进行数据写入操作,再次请求时,请求到达从节点,如果写请求没有被同步到从节点,从节点对客户端响应的就是过期的数据。
所以,主从之间,不是强一致的,而是弱一致性,最终一致。
但是,当某个主节点挂了之后,该主节点剩余的从节点就会进行leader选择,这时使用的是raft协议进行leader的选择,就是强一致性的协议,leader的选举过程是CP的。
综上,Redis哨兵和Redis集群对外提供服务时,是AP型的应用。在leader选举的过程中,是CP的。(CP这个描述可能不太对,是我自己的理解)

总结和理解

对于AP行的注册中心,每个节点都可以对客户端的请求进行响应。而对于CP型的注册中心,只能由leader对客户端进行响应。
AP型应用的写请求响应时间更快、写并发能力更强,但是客户端获取到的可能是过期的数据,有数据一致性问题。
CP型的应用的写请求响应时间慢,写并发能力弱,但是客户端获取到的是最新的数据,没有数据一致性问题。

参考

网易一面:Eureka怎么AP?Nacos既CP又AP,怎么实现的?

注册中心的AP和CP 注册中心有什么用

凤凰架构:分布式事务

【谈一谈】Redis是AP还是CP?


原文地址:https://blog.csdn.net/qq_26432153/article/details/137892934

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!