CAP原理分析和具体应用
CAP简介
C–一致性 Consistency 在同一时刻的同一请求的实例返回的结果相同,所有的数据要求具有强一致性
A–可用性 Availability 所有的实例的读写请求在一定时间内可以得到正确的响应
P–分区容错性 Partition tolerance 在网络异常(比如:挖断光缆、设备故障、宕机)的情况下,系统仍然能提供正确的服务
以上的上特点就是CAP原则(又称CAP定理),但是这三个特性是不可能同时满足的,所以分布式系统设计要考虑的是在满足P(分区容错性)的前提下选择C(一致性),还是A(可用性),即:CP或AP
CP系统 zookeeper
AP系统 eureka
Nacos 比较特别,像大部分的注册中心(协调一致性组件)基本上都是职场单一的模式,例如上述2种,二nacos同时支持了cp与ap两种协同模式,由此延伸出2个问题,这两种模式有什么区别?怎么进行配置?
分区容错性如何提供的?
为了解决当前可能存在的"分区容错性"的设计思想,我们在整个的项目架构之中引入了多个Nacos服务节点,而这多个Nacos服务节点彼此之间所保存的数据是相同的,但是毕竟是在整个的处理之中是向一个Nacos节点进行注册数据处理的,可是这些数据却可以自动的同步到其他的节点
引入Nacos服务集群的可以提高服务注册与发现的处理性能,在实际的Nacos运行过程中,每一个Nacos数据节点都会保存自己的配置数据,由于集群的每个节点都需要满足数据的修改与获取的功能需求,所以就需要满足数据的修改与获取共轭能需求,所以就需要讲集群中的节点数据进行自动同步处理,即:某一个节点数据发生改变时将同步到其他节点.
Nacos服务集群之中会包含有众多的数据节点,这样所有的数据可以分别保存在不同的数据节点之中,一点某一个节点发生了故障,应该可以及时的满足分区容错性(p原则)设计要求,即:可以直接通过其他非故障节点获取所需要的数据项.
除了一些无法预见的外力之外,一般情况下很少会出现完全奔溃的可能性(突然出现了某些热点的话题,用户蜂拥而至),像机房停电、网络损坏等等.虽然通过若干个节点可以实现数据的分区存储,但是这若干个节点之间毕竟要有数据同步的需要,所以这个时候在进行数据处理时,就存在有两种实现原则:一致性原则(c原则)、可用性原则(A原则)
CP原则–一致性原则+分区容错性原则
cp原则就是 强一致性原则,要求所有节点可以查询到的数据随时随刻都保存一致(同步中的数据不可查询),即:若干个节点形成一个逻辑的共享区域,某一个节点更新的数据都会立即同步到其他数据节点之中,当数据同步完成后才能返回成功的结果,但是在实际的运行过程中,网络在所难免,如果此时若干服务节点之间无法通讯时就会出现错误,从而牺牲了可用性原则(A原则)
类比概念:
在关系型数据库之中最大的特点在于事务管理,而事务管理所带来的直接问题就是性能下降,事务 这种概念就属于一直强一致性的原则,所有的操作必须打好招呼了,都完成操作了,最终才可以实现整个的事务处理.
在Nacos中的CP原则实现依靠的是Raft算法,在Raft将一致性算法分为了几个部分,包括领导选取(Leader Selection)、日志复制(Log Replication)、安全(Safety),并且使用了更强的一致性来减少了必须需要考虑的状态.在Raft算法中法将服务端节点划分为三种不同的转台(或许称为角色):
领导者(Leader): 负责客户端交互以及一般日志复制,在同一时刻的集合环境中只为最多存在一个Leader;
跟随者(Follower): 被动请求的节点,跟随Leader实现数据同步
候选人(Candidate): 一个临时角色,只存在于Leader选举阶段,某个节点要想称为Leader,就需要 发出投票请求,同时自己也将变为Candidate转台,如果选举成功则变为Leader,否则退回为Follower.
Nacos源代码中有一个"consistency"模块,这个模块分别有AP和CP两个接口,和实现类 ,去实现AP和CP算法
CP缺点:是一个强关联的操作形式,所以一旦有某些节点,出现了问题后,所带来的最终问题就是整个的数据更新失败,如果只是在一个机房内,那么CP模式就没有任何问题,但是一定要跨区域就会出现数据更新失败的情况.
AP原则–可用性原则+分区容错性原则
AP原则属于弱一致性原则，在集群中只要有存活的节点那么所发送来的所有请求都可以得到正确的响应，在进行数据同步处理操作中即便某些节点没有成功的实现数据同步也返回成功，这样就牺牲一致性原则(C原则)。
AP使用形式:对于数据的同步一定会发出指定,但是最终的节点是否真的实现了同步,并不一定肯定,可是却可用技术的得到数据更新成功的响应,可以应用在网络环境不那么好的场景
在Nacos 中的AP原则实现主要依靠的是Distro协议实现，该协议是阿里巴巴的私有协议，是一种定位临时数据的一致性协议。在该协议中不需要把数据存储到磁盘或者数据库之中，因为临时数据通常会和服务器保持有一个session会话，只要该会话存在，数据就不会消失。在 Distro 协议中服务端接收到数据后，会由服务端的负责节点实现数据写入后返回，而后台会将这些数据异步发送给其他节点。
阿里在进行Nacos设计的时候充分的考虑到了市场化的运作（市面上大多都是以单一的实现形式为主的，例如:ZooKeeper使用的是CP、而Eureka采用的是AP)，在nacos中提供了两种模式的动态切换。
切换为CP模式:
curl -X PUT “nacos-proxy:8848/nacos/v1/ns/operator/switches?
entry=serverMode&value=CP&username=nacos&password=nacos”
切换为AP模式:
curl -X PUT “nacos-proxy:8848/nacos/v1/ns/operator/switches?
entry=serverMode&value=AP&username=nacos&password=nacos”
注意:模式调整之前一定要区分出所应用的项目的场景,而后根据场景确定好后就别总是随机修改了