RuoYiplus 使用Eureka作为注册中心,说到注册中心首先想到的应该是‘’分布式”,分布式系统有个著名的理论—CAP理论【Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)】
著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。Eureka保证的是AP,Zookeeper则保证的是CP。
zk使用的是ZAB协议(Zookeeper 原子广播协议),ZooKeeper它所做的就是确保对数据的修改都会被复制到集合体中超过半数的节点上。如果少于半数的机器出现故障,则最少有一台机器会保存最新的状态,那么这台机器就是我们的Leader。其余的副本最终也会更新到这个状态。如果 Leader挂了,由于其他机器保存了Leader的副本,那就可以从中选出一台机器作为新的Leader继续提供服务。
从原则上来说,zookeeper保证了强一致性,但实际上写操作的2pc提交不需要所有的节点都投票通过,而是超过半数的节点投票通过即可,那么有的节点有可能没有第一时间接收到写操作的同步而leader已经通过该写操作,这样的话连接到该节点的服务只能说得到了数据单调一致性的保障,而不是强一致性的保障。但是总的来说,zookeeper是相当偏向于一致性而非可用性的服务注册与管理中间件,需要注意的是这也会大幅度增加写入数据的性能成本,但是一般情况下作为服务中心写入的数据并不多,还在可接受的范围内。(以上为网上资料)
相对于zookeeper,eureka相当偏向于A而非C,即是说一台连接不到集群的eureka节点依然可以对外提供服务,即使提供的数据不一定是最新的,但是在某些情况下总比服务之间宕机要好。
在eureka集群中,如果某个节点发生宕机,eureka不会有类似zookeeper选举的行为,即不会对外停止服务。客户端请求会切换到别的eureka节点,当宕机的服务器重新恢复后会被再次加入集群管理中同步别的eureka server保存的注册信息。当网络分割故障发生时,每个eureka server节点都能继续对外提供服务。
eureka server还有心跳机制,默认情况下eureka server一段时间内没有接受服务提供者发送的心跳就会将其剔除,但是也有可能是eureka server发生了网络分区故障。如果eureka server在一段时间内丢失了大量心跳,那么会进入自我保护模式,此时有以下行为模式:
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上,保证当前节点依然可用。
3、当网络稳定时,当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况,而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。
eureka client还拥有缓存功能,即使所有的eureka server都不可用,那么client依然能够使用本地缓存连接已缓存的一些服务。 (以上为网上资料)