zookeeper和Eueaka区别

一，关于Eueaka

Eureka 是 Netflix 的一个子模块，也是核心模块之一。Eureka 是一个基于 REST（REpresentational State Transfer） 的服务，用于定位服务，以实现云端中间层服务器的负载均衡和故障转移。Eureka还附带了一个基于java的客户端组件——Eureka Client，它使得与服务的交互更加容易。Eureka Client 还有一个内置的负载均衡器，可以进行基本的循环负载均衡，在 Netflix，一个更加复杂的负载均衡器封装了 Eureka，可以根据流量、资源的使用情况、错误条件等因素根据自定义的权重来实现负载均衡，从而提供更好的弹性服务。

对于服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。

 

2、Eureka 基本架构原理

Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，则使用 Eureka Client 连接到 Eureka Server 并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。Spring Cloud 的一些其他子模块（例如 Gateway）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的业务逻辑。一个 Eureka 的高可用架构图如下（后面会专门的一篇文章来描述如何实现高可用）：

 

 

上面图描述了 Eureka 是如何部署在 Netflix 上的，这是 Eureka 典型的使用案例。每个区域都有一个 Eureka 集群，而这个 Eureka 集群只知道该区域中的实例。每个区域至少有一个 Eureka 服务器来处理该区域故障（故障转移）。

关于 Eureka 的更多内容，请查看《 Eureka 基本原理及其架构概述 》

二，关于zookeeper

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，其主要功能包括：配置维护、域名服务、分布式同步、组服务管理等。

ZooKeeper 的目标就是错综复杂的、易出错的服务封装起来，将简其单易用的接口和性能高效、功能稳定的系统服务暴露出来并提供给用户调用使用。

 

3、Zooekeeper 基本原理

ZooKeeper 是以 Paxos 算法为基础的，而Paxos 算法存在活锁的问题，即当有多个 proposer 交错提交时，有可能互相排斥导致没有一个 proposer 能提交成功，而 Paxos 作了一些优化，通过选举产生一个leader （领导者），只有 leader 才能提交 proposer。

*注：所谓的 Paxos 算法是一种基于消息传递的一致性算法，并且该算法被认为是类似算法中最有效的。

ZooKeeper 的基本运行流程：
1、选举 Leader（所以一般要求3个，或者以上）。
2、同步数据。
3、选举 Leader 过程中算法有多中，但最终的选举标准是一致的。
4、Leader 被赋予最高的执行ID（竞选成功后的授权），其执行ID类似于Linux中的root权限。
5、集群中服务得到通知并一致的认可选出的 Leader。
6、Leader 服务器宕机，进入1）步，再次进行 Leader 选举。
详细参考：https://www.cnblogs.com/niwa/p/11053135.html

 

三，Eueaka和zookeeper在分布式系统上的作用的区别

Eueaka在分布式系统中是保证AP，而zookeeper是保证AP

3.1 简单介绍CAP理论

 

CAP 原则又称 CAP 定理，1998年，加州大学的计算机科学家 Eric Brewer 提出的，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得（我们常说的鱼和熊掌不可兼得）。CAP 原则也是 NoSQL 数据库的基石。

1、一致性（Consistency，C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。

2、可用性（Availability，A）：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求。（对数据更新具备高可用性）。

3、分区容错性（Partition tolerance，P）：大多数的分布式系统都分布在多个子网络中，而每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如阿里巴巴的服务器（不知道各位有没有发现，不管你到那个城市去，你访问的服务器总是该城市的，其中使用 了算法，由于篇幅有限就不再这儿一一讲解了），一台服务器放在上海，另一台服务器放在北京，这就是两个区，它们之间可能存在无法通信的情况。在一个分布式系统中一般分区容错是无法避免的，因此可以认为 CAP 中的 P 总是成立的。CAP 理论告诉我们，在 C 和 A 之间是无法同时做到。
 详细参考：CAP细节https://www.cnblogs.com/niwa/p/11063526.html

 

Spring Cloud Eureka  -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则。Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构（参看：微服务与微服务架构思想与原则），无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

 

在Eureka平台中，如果某台服务器宕机，Eureka不会像zookeeper选择leader的过程，客户端请求会自动切换到新的Eureka节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理中，而对于它而言，所有要做的无非是同步一些新的服务注册信息。所以不用担心“掉队”的服务器恢复以后，会从Eureka服务器集群中踢除的风险。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现0宕机维护需求。（多个zookeeper之间网络出现问题，造成出现多个leader，发生脑裂），当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（zookeeper不会）接收新的服务注册同时将它们提供下游的服务发现请求，这样一来，就可以实现在同一个子网中，新发布的服务仍然可以被发现与访问。

        Eureka还有客户端缓存功能（Eureka分为客户端程序与服务端程序两个部分，客户端程序负责向外提供注册与发现服务接口）所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。

Apache Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的幺六八就是紧遵AP的最好参照）。

ZK主要使用场景远不是满足最初设计时对一致性调解的需求，这么受欢迎是因为其灵活的特性设计，只要简单组合就能满足很多种需求，同样将特性的受欢迎程度按照个人感觉从高到低进行说明

1. 通知回调机制，通过创建节点与设置Watcher可以很方便的建立回调通知。ZK的所有应用都基于这个特性，没有这个机制那么机器监控相关的应用都不能处理，也就不会诞生后来在服务注册发现相关的使用方法。实际上为分布式系统提供节点间回调通知方法的系统真的很少，甚至可能只有ZK（大家可以提供一些其他答案？）
2. 可靠存储系统，设计最初的需求之一，也是ZK特性中实现最好的部分，作为可靠存储ZK基本没出现过问题，仅此一项就可保证其的流行。
3. 连接状态维护，ZK自动维护了客户端所在的应用与服务器通信连接状态的变化，可以比较简单地维护系统中的成员通信情况。主要是不需要自己再去处理麻烦的通信状态监控问题，比如断线后自动释放节点并产生回调。
4. 文件系统模型，提供文件接口模型而不是锁接口，更具通用性。文件系统模型中文件与目录的概念可以映射多种含有层级关系的其他模型
5. 自增长序列，这点包含了锁的本质，但是因为zk的模型设计导致判断与仲裁需在客户端进行

3.2.实现技术选择与优点

ZK本身的系统特性设计很出色，同时选择的实现技术也比较扎实，可谓蕴含相当的分布式系统工程经验在其中。下面结合个人理解讨论下这些实现技术有哪些特别优点与选择时可能的设计思路。

1. 1.  通讯机制与状态的实现
      基于jute进行编解码处理保证通用性，服务器端通信使用nio或netty都是标准选择。
   2.  Zab协议与Paxos
      zk使用Zab协议保证部署的多台机器间构成的整体系统的一致性与可靠性。这个分布式协议类似Paxos但是更加具体有效，实际上Paxos工程实现会碰到很多协议中没有定义的问题,G家员工为在Chubby中使用Paxos算法甚至专门发了一篇文章来说明Paxos工程化踩了多少坑。
      Zab协议中将选主阶段与正常运行之间的阶段用catch up方式进行弥补，而关键的选主阶段使用了一个极其工程化的算法“fast leader election”（这个算法似乎没有经过形式化证明），这个算法足够粗暴有效，实现起来很简单。
      最近Paxos的工程简化版算法Raft很火，所有考虑使用Paxos的系统都在实现Raft协议，其过程与Zab协议很类似，但是选主算法更加简单（可能实现结果是比Zab选主更慢）而且无法如Zab一样简单替换这个部分的算法。个人看法是Zab协议比Raft其实更容易理解，而且容易工程实现。（为何没有Raft火爆？可能是因为Zab协议选主部分设计的过于复杂，但是Raft目前还没有工业级的系统进行验证）
   3.  使用JVM
      zk作为一个以稳定性与一致性为主的系统，性能上面肯定有一点损失。相信大家实现这种系统首先都会考虑要利用语言本身的速度优势尽量弥补系统的性能损失，于是我们就能看到很多c++实现的类zk系统（比如Chubby)，但是这些新系统却没有zk的普及率。
      可以说zk的流行中很重要的一点就是牺牲部分可能的性能使用JVM作为底层。正是因为虚拟机的使用屏蔽了各种异构系统底层，让zk可以很容易的稳定部署在多台配置性能都可能各异的机器上。个人理解这也是为什么现在那么多分布式系统都基于JVM技术栈，分布式系统需求的机器多，不可能所有配置都一样，而且机器都需要很容易进行物理替换或是系统升级，目前还只有JVM可以非常简单的提供这种等级的虚拟化屏蔽。
      当然最近docker容器技术大放异彩，轻量级虚拟化方案以极快的速度兴起，让各种异构系统有了更简单可定制的底层虚拟化方式，也许有可能改变分布式系统的底层技术栈。

 

四，为什么canal需要用到zookeeper

使用zookeeper作为canal的集群管理：

1，zookeeper保证一致性，zookeeper作为canal的集群管理中心，则每个canal节点的数据都是一致的，当一个canalA服务节点挂掉，zookeeper则会切换到另一个canalB服务节点，在切换过程，如果数据不一致，会导致canalA的解析的数据丢失。

2，zookeeper实现分布式锁，避免了集群上的服务竞争某个资源，引起死锁

 

参考：https://blog.csdn.net/Hello_World_QWP/article/details/85247142

http://www.chaozh.com/whats-good-in-zookeeper-design/

 

转载于:https://www.cnblogs.com/niwa/p/11076135.html