分布式架构设计里的Eureka与ZooKeeper区别理解

前言

一个系统最重要的是什么?是数据。数据放在哪?数据库里。但是光有数据也不行,还需要程序对数据进行各种增删改查操作。

那各种增删改查操作,最重要的是什么?是数据的安全性、可扩展性和性能。

数据库又分关系型数据库和非关系型数据库。

关系型数据库RDBMS(Relational database management system)MySQL、SQL server、Oracle我们都经常用,其遵循的事务原则是ACID原则(Atomicity:原子性、Consistency:一致性、Isolation:隔离性、Durability:持久性)

非关系型数据库NoSQL(Redis、MongoDB)遵循的原则是CAP原则一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。

分布式系统架构设计

我们在进行分布式架构设计时,关系数据库的很多主要特性却往往无用武之地。

数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求

对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

对复杂的SQL查询,特别是多表关联查询的需求。

任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

而与之不同的是,NoSQL系统通常注重性能和扩展性,而非事务机制(事务就是强一致性的体现)。

cap原则

CAP理论也就是说在分布式存储系统中,最多只能实现以上两点。而由于当前网络延迟故障会导致丢包等问题,所以我们分区容错性是必须实现的。也就是NoSqL数据库P肯定要有,我们只能在一致性和可用性中进行选择,没有Nosql数据库能同时保证三点。(==>AP 或者 CP)。

提出一个想法,当你面对双十一这种业务处理时,你是选择AP还是CP呢?

个人想法是在面对这种业务处理时,先保证可用性也就是AP原则(服务器不能瘫痪),在过了双十一高峰,再核对数据,保证数据一致性。

Eureka和ZooKeeper的区别

综上,我们在进行分布式架构设计时,就必须针对上面提到的cap原则做出取舍。

一般是通过分布式缓存中各节点的最终一致性来提高系统的性能,通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 redis 之类的 NOSQL 作为实现手段。

Eureka和Zookeeper就是CAP定理中的实现,Eureka(保证AP),Zookeeper(保证CP)

zookeeper保证cp

当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

Zookeeper的设计理念就是分布式协调服务,保证数据(配置数据,状态数据)在多个服务系统之间保证一致性,这也不难看出Zookeeper是属于CP特性(Zookeeper的核心算法是Zab,保证分布式系统下,数据如何在多个服务之间保证数据同步)。Eureka是吸取Zookeeper问题的经验,先保证可用性。

0

发表评论

邮箱地址不会被公开。