㈠ zookeeper 用到哪些设计模式
ZooKeeper作为发现服务的问题
ZooKeeper(注：ZooKeeper是着名Hadoop的一个子项目，旨在解决大规模分
布式应用场景下，服务协调同步(Coordinate
Service)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它
很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。
在分布式系统领域有个着名的 CAP定理(C-
数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个
CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就
是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的
职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性
的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且，
作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算
是
返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能
因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨
了!
而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题;而在云端，网络分割问题跟其他类型的
故障一样的确会发生;所以最好提前对这个问题做好100%的准备。就像 Jepsen在
ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区(partition)的节点数(nodes)数达不到
ZooKeeper选取Leader节点的逗法定人数地时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。
如果给ZooKeeper加上客户端缓存(注：给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网
络故障造成节点同步信息错误的问题。 Pinterest与 Airbnb公
司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况
下，每个节点还可以从本地缓存中获取到数据;但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果
ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper
会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是逗健康地的，可以正常提供服务的;所以导致到达这些节点的服务请求
被丢失了。(注：这也是为什么ZooKeeper不满足CAP中A的原因)
更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法
的
目的是为了让ZooKeeper变得更加可靠(available);但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样
一来，你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为，这相当于你在一个已有的CP系统上强制栓了
一个AP的系统，这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行!
如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生，
导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台
很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作，如：正确的重建观察者(reestablishing
watcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时，我们确实也遇到过
ZooKeeper的一些经典bug： ZooKeeper-1159 与 ZooKeeper-1576;
我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务
群的Session与网络连接资源(注：这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现，所以使用ZooKeeper当
Service发现服务得不偿失。
做出正确的选择：Eureka的成功
我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开
源的服务发现解决方案，由Netflix公司开发。(注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作
服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。)Eureka一开
始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。(
他们都在讨论Eureka)。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过，在云平
台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用!
首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切
换
到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务
注册信息而已。所以，再也不用担心有逗掉队地的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广
的网络分割故障，并实现逗0地宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新
的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of
partition)，新发布的服务仍然可以被发现与访问。
但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些逗濒死地的服务器;如果在Eureka中注册的服
务，
它的逗心跳地变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时，
这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很地健康逗的，只是因为网络分割故障把Eureka集群分割
成了独立的子网而不能互访而已。
幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个
Eureka节点会进入地自我保护模式逗，同时保留那些逗心跳死亡逗的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对
于地死亡逗的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出地自我保护模式逗。所以Eureka的哲学是，同时保
留地好数据逗与地坏数据逗总比丢掉任何地好数据逗要更好，所以这种模式在实践中非常有效。
最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接
口)。
所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过
Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解
决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，
这
样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心
跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源
的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。
维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一
个
web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供
了Restful-API接口，方便第三方程序集成Eureka的功能。
㈡ Zookeeper在哪些系统中使用，又是怎么用的
ZooKeeper作为发现服务的问题 ZooKeeper(注：ZooKeeper是着名Hadoop的一个子项目，旨在解决大规模分 布式应用场景下，服务协调同步(Coordinate Service)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它 很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。 在分布式系统领域有个着名的 CAP定理(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就 是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的 职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性 的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且， 作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。 作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算 是 返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能 因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨 了! 而且更何况，如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题;而在云端，网络分割问题跟其他类型的 故障一样的确会发生;所以最好提前对这个问题做好100%的准备。就像 Jepsen在 ZooKeeper网站上发布的博客中所说：在ZooKeeper中，如果在同一个网络分区(partition)的节点数(nodes)数达不到 ZooKeeper选取Leader节点的“法定人数”时，它们就会从ZooKeeper中断开，当然同时也就不能提供Service发现服务了。 如果给ZooKeeper加上客户端缓存(注：给ZooKeeper节点配上本地缓存)或者其他类似技术的话可以缓解ZooKeeper因为网 络故障造成节点同步信息错误的问题。 Pinterest与 Airbnb公 司就使用了这个方法来防止ZooKeeper故障发生。这种方式可以从表面上解决这个问题，具体地说，当部分或者所有节点跟ZooKeeper断开的情况 下，每个节点还可以从本地缓存中获取到数据;但是，即便如此，ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果 ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的;所以导致到达这些节点的服务请求 被丢失了。(注：这也是为什么ZooKeeper不满足CAP中A的原因) 更深层次的原因是，ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法 的 目的是为了让ZooKeeper变得更加可靠(available);但是，ZooKeeper设计的本意是保持节点的数据一致，也就是CP。所以，这样 一来，你可能既得不到一个数据一致的(CP)也得不到一个高可用的(AP)的Service发现服务了;因为，这相当于你在一个已有的CP系统上强制栓了 一个AP的系统，这在本质上就行不通的!一个Service发现服务应该从一开始就被设计成高可用的才行! 如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难;错误会 经常发生， 导致很多工程被建立只是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身。Knewton平台 很多故障就是由于ZooKeeper使用不当而导致的。那些看似简单的操作，如：正确的重建观察者(reestablishing watcher)、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时，我们确实也遇到过 ZooKeeper的一些经典bug： ZooKeeper-1159 与 ZooKeeper-1576; 我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现，在于ZooKeeper需要管理与保障所管辖服务 群的Session与网络连接资源(注：这些资源的管理在分布式系统环境下是极其困难的);但是它不负责管理服务的发现，所以使用ZooKeeper当 Service发现服务得不偿失。 做出正确的选择：Eureka的成功 我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开 源的服务发现解决方案，由Netflix公司开发。(注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。)Eureka一开 始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色。( 他们都在讨论Eureka)。自从切换工作开始到现在，我们实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过，在云平 台做服务迁移注定要遇到失败;但是我们从这个例子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用! 首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切 换 到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of partition)，新发布的服务仍然可以被发现与访问。 但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服 务， 它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时， 这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。 幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。 最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接 口)。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。 Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制， 这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源 的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。 维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一 个 web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供 了Restful-API接口，方便第三方程序集成Eureka的功能。
㈢ bbo使用zookeeper连接，zookeeper宕机后怎么处理
zookeeper宕机后，因为消费者会缓存提供者的信息，所以应用不会有问题。但是，此时提供者和消费者都无法重连zookeeper，因为bbo貌似配置的zkclient不会重连zookeeper，所以一旦重启一台服务提供者，那么这台就从服务消费者的缓存中消失了，此时服务消费者又连不上zookeeper，所以如果同时重启，消费者就没有提供者可用了，所以只能重启一台提供者后，再重启一个消费者，交错重启。
㈣ 如果 zookeeper挂了 我们以前调用过的 服务 还能用吗是不是缓存在本地
可以的，启动bbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用
注册中心对等集群，任意一台宕掉后，会自动切换到另一台注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
服务提供者无状态，任一台 宕机后，不影响使用服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复
㈤ 为什么bbo使用zkclient作为zookeeper的客户端
本文内容并非原创，使用资料均来自互联网。
bbo使用了zkClient而不是使用zookeeper本身的客户端与zookeeper进行交互，为什么呢？
先看看zookeeper本身自带的客户端的问题。
1 ） ZooKeeper的Watcher是一次性的，用过了需要再注册；
2 ）
session的超时后没有自动重连，生产环境中如果网络出现不稳定情况，那么这种情况出现的更加明显；
3
）
没有领导选举机制，集群情况下可能需要实现stand by，一个服务挂了，另一个需要接替的效果；
4
） 客户端只提供了存储byte数组的接口，而项目中一般都会使用对象。
5 ）客户端接口需要处理的异常太多，并且通常，我们也不知道如何处理这些异常。
I0Itec这个zookeeper客户端基本上解决了上面的所有问题，主要有以下特性：
1) 提供了zookeeper重连的特性------能够在断链的时候,重新建立连接,无论session失效与否.
2) 持久的event监听器机制------ ZKClient框架将事件重新定义分为了stateChanged、znodeChanged、dataChanged三种情况，用户可以注册这三种情况下的监听器（znodeChanged和dataChanged和路径有关），而不是注册Watcher。
3) zookeeper异常处理-------zookeeper中繁多的Exception,以及每个Exception所需要关注的事情各有不同，I0Itec简单的做了封装.
4) data序列化------简单的data序列化.(Serialzer/Deserialzer)
5）有默认的领导选举机制
请注意使用I0Itect-zkClient暂时有几个方法仍需要重写:
1) create方法 : 创建节点时,如果节点已经存在,仍然抛出NodeExistException,可是我期望它不在抛出此异常.
2) retryUtilConnected : 如果向zookeeper请求数据时(create,delete,setData等),此时链接不可用,那么调用者将会被阻塞直到链接建立成功;不过我仍然需要一些方法是非阻塞的,如果链接不可用,则抛出异常,或者直接返回.
3) create方法 : 创建节点时,如果节点的父节点不存在,我期望同时也要创建父节点,而不是抛出异常.
4) data监测: 我需要提供一个额外的功能来补充watch的不足,开启一个线程,间歇性的去zk server获取指定的path的data,并缓存起来..归因与watch可能丢失,以及它不能持续的反应znode数据的每一次变化,所以只能手动去同步获取。
㈥ java zookeeper怎么清除缓存
掌握zookeeper事件监听机制，非常重要，可以说是跨入了进阶的门槛，只有掌握了如何监听某个节点或路径，我们才能在节点变化后，做一些我们想做的事，包括： 1，配置文件同步 2，主从切换 3，分布式队列 4，分布式锁
㈦ bbo使用zookeeper连接，zookeeper宕机后怎么处理
1、配置文件同步
2、主从切换
3、分布式队列
4、分布式锁
㈧ 那 如果 zookeeper 挂了 我们以前调用过的 服务 还能用吗是不是缓存在本地
不可用了，zk是强一致性
㈨ 为什么不使用ZooKeeper
ZooKeeper作为发现服务的问题；
ZooKeeper(注：ZooKeeper是着名Hadoop的一个子项目，旨在解决大规模分 布式应用场景下，服务协调同步(Coordinate Service)的问题；
它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目；
有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来Service发现服务解决方案则是个错误。
㈩ zookeeper 节点 是缓存吗
Zookeeper作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是Zookeeper并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。...