springCloud之Eureka2-创新互联
Eureka和Zookeeper的区别
分享标题:springCloud之Eureka2-创新互联
标题路径:http://scyanting.com/article/ggioj.html
CAP原则
CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
ACID原则
ACID原则是数据库事务正常执行的四个,分别指原子性、一致性、独立性及持久性
CAP原则的三进二:CA CP AP
CAP理论的核心
- 一个分布式系统,不可能同时很好的满足一致性,可用性,分区容错性这三个需求
- 根据CAP原则,其精髓是要么AP,要么CP,要么AC
- CA :单点集群,满足一致性,可用性,一般扩展性较差
- CP:满足一致性,分区容错性,一般系统性能不是太高
- AP:满足可用性和分区容错性,牺牲了一致性
作为分布式的注册中心,分区容错性是必须具备的,那么区别 就是C和A的选择。
- Zookeeper选择的了CP
- Eureka 选择了AP
Zooceeper保证的是CP
当我们向注册中心查询服务时,我们可以允许注册中心返回的是几分钟之前的注册信息,但是无法接受注册中心直接down掉,无法使用,也就是希望其可用性高于一致性。但是zk会出现这种情况。当zk集群的master因网络波动等原因与其他节点失去联系后,zk集群会重新选举出一个新的leader,这个选举的过程耗时较长30-120s,而且在这个选举过程中,整个zk集群是无法使用的,处于瘫痪状态。
在现下的云环境中,因为网络波动导致zk继续master和其他节点失去联系是非常容易出现的事情,虽然最后能够恢复,但是漫长的选举时间导致注册无法使用是难以接受的。
Eureka
Eureka就是看到了这一点,所以在设计时优先保证了可用性,Eureka的各个节点之间时平等的,几个节点挂掉,不影响其他节点继续提供服务,当Eureka客户端向服务端注册服务时,发现当前节点无法连接,会继续向下一节点注册服务,只要有一台Eureka节点存在,就能保证可用性,只是查询的服务不一定是最新的。
Eureka还有一种自我保护机制,如果15分钟内,有85%的节点没有正常的心跳,那么就任务服务端和客户端之间产生了网络波动,会有以下几种情况出现:
1.Eureka不在从注册列表中移出因长时间没有心跳而应该过期的服务。
2.Eureka依然会接受新的注册和查询服务,但是不会同步到其他节点上(保证当前节点可用)
3.待网络稳定后,向其他节点同步新的服务
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
分享标题:springCloud之Eureka2-创新互联
标题路径:http://scyanting.com/article/ggioj.html