zookeeper 实际使用场景举例

         本人所在的项目组，目前在两个地方使用到了zookeeper，分别是

     1.定期理财平台：理财涉及到一个额度的问题，不同的渠道（如网站、手机、微信等）使用的是同一个额度，需要确保每个渠道看到的都是同一个额度。所采取的方式就是在产品后台数据库维护产品的实时额度，然后通过zookeeper推送给不同的渠道。

     2.线上房贷平台：这里主要是用zookeeper进行楼盘信息的推送。后台管理人员在后台管理系统进行楼盘信息的编辑，所有的编辑之后的信息，再通过zookeeper推送到不同的平台进行展示。

     另外收集了一些国际国内的典型应用，供大家参考：

     1. metaq：MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，思路起源于LinkedIn的Kafka，但并不是Kafka的一个Copy。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，目前在淘宝和支付宝有着广泛的应用。 metaq发送消息的时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此metaq在运行过程中，会把所有broker和对应的分区信息全部注册到ZK指定节点上，默认的策略是一个依次轮询的过程，生产者在通过ZK获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。消费负载均衡：在消费过程中，一个消费者会消费一个或多个分区中的消息，但是一个分区只会由一个消费者来消费。MetaQ的消费策略是：

      每个分区针对同一个group只挂载一个消费者。

      如果同一个group的消费者数目大于分区数目，则多出来的消费者将不参与消费。

      如果同一个group的消费者数目小于分区数目，则有部分消费者需要额外承担消费任务。

在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过 zookeeper watch消费者列表），然后重新进行负载均衡，保证所有的分区都有消费者进行消费。

     2. Dubbo：阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。在Dubbo实现中：

     服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。

     服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。

     注意，所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。

     另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。

     3. Apache HBase：Hbase是一个通常与Hadoop一起使用的数据仓库。在Hbase中，zookeeper用于选举一个集群内的主节点，以便跟踪可用的服务器，并保存集群的元数据。