|
1：zookeeper 作用
zookeeper是hadoop下的一个子项目，旨在解决大规模分布式应用场景下，服务协调同步的问题，它可以为同一个分布式系统中的其他服务提供：统一命名，配置管理，分布式锁服务，集群管理等功能。
2：zookeeper 的劣势
在分布式系统领域中有个著名的CAP定律（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性）这三个特定在任何分布式系统中都不能同时满足，最多同事满足2个。
zookeeper是CP的。
(1.) 即任何时刻对zookeeper的访问请求能得到一致的数据结果( 用的是主从集群架构):
1）Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
4）更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。
5）数据更新原子性，一次数据更新要么成功，要么失败。
6）实时性，在一定时间范围内，Client能读到最新数据。
（2.） 同时系统对网络分区具有容错性；
1)这个就是副本容灾
但是它不保证每次服务请求都是可用的。极端环境下，zookeeper会丢弃一些请求，消费者端需要重新请求才能得到结果（zookeeper为什么不设计成AP的？）。作为zookeeper的核心算法Zab（zookeeper Atomic Broadcast，全称：原子消息广播协议），就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
zookeeper 下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果zookeeper下所有的节点都断开了，或者集群中出现了网络分割的故障，那么zookeeper将会把他们从自己的管理范围内踢除，外界就不能访问到这些节点了，即使这些节点本身是健康的可以正常提供服务，所以导致到达这些节点的服务请求被丢失了。
3：Eureka的优势
在Eureka平台中，如果某台服务器宕机，Eureka不会像zookeeper选择leader的过程，客户端请求会自动切换到新的Eureka节点，当宕
机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理中，而对于它而言，所有要做的无非是同步一些新的服务注册信息。所以不
用担心“掉队”的服务器恢复以后，会从Eureka服务器集群中踢除的风险。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现0宕
机维护需求。（多个zookeeper之间网络出现问题，造成出现多个leader，发生脑裂），当网络分割故障发生时，每个Eureka节点，会持
续的对外提供服务（zookeeper不会）接收新的服务注册同时将它们提供下游的服务发现请求，这样一来，就可以实现在同一个子网中，新发
布的服务仍然可以被发现与访问。
Eureka还有客户端缓存功能（Eureka分为客户端程序与服务端程序两个部分，客户端程序负责向外提供注册与发现服务接口）所以即
便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以
通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好
的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
|