折腾了一周多终于跑起来了，贵在实践。
参考地址：
指南地址 http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html 单机安装 http://blog.csdn.net/done58/article/details/51004703 入门 http://www.tuicool.com/articles/JN73YrM ZooKeeper 安装部署 http://blog.csdn.net/huwei2003/article/details/49101269 集群和伪集群 http://coolxing.iteye.com/blog/1871009 集群搭建 http://blog.csdn.net/beitiandijun/article/details/41802835
关于zookeeper的一些介绍
引子 云计算越来越流行的今天，单一机器处理能力已经不能满足我们的需求，不得不采用大量的服务集群。服务集群对外提供服务的过程中，有很多的配置需要随时更新，服务间需要协调工作，这些信息如何推送到各个节点？并且保证信息的一致性和可靠性？ 众所周知，分布式协调服务很难正确无误的实现，它们很容易在竞争条件和死锁上犯错误。如何在这方面节省力气？Zookeeper是一个不错的选择。 Zookeeper背后的动机就是解除分布式应用在实现协调服务上的痛苦。本文在介绍Zookeeper的基本理论基础上，用Zookeeper实现了一 个配置管理中心，利用Zookeeper将配置信息分发到各个服务节点上，并保证信息的正确性和一致性。 Zookeeper是什么？ 引用官方的说法：“Zookeeper是一个高性能，分布式的，开源分布式应用协调服务。它提供了简单原始的功能，分布式应用可以基于它实现更高级 的服务，比如同步，配置管理，集群管理，名空间。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在java上，提供java和C的客户端 API”。 Zookeeper总体结构 Zookeeper服务自身组成一个集群(2n+1个服务允许n个失效)。Zookeeper服务有两个角色，一个是leader，负责写服务和数据同步，剩下的是follower，提供读服务，leader失效后会在follower中重新选举新的leader。 Zookeeper逻辑图如下， 客户端可以连接到每个server，每个server的数据完全相同。 每个follower都和leader有连接，接受leader的数据更新操作。 Server记录事务日志和快照到持久存储。 大多数server可用，整体服务就可用。 Zookeeper数据模型 Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）。 数据模型结构图如下， 圆形节点可以含有子节点，多边形节点不能含有子节点。一个节点对应一个应用，节点存储的数据就是应用需要的配置信息。 Zookeeper 特点 顺序一致性：按照客户端发送请求的顺序更新数据。 原子性：更新要么成功，要么失败，不会出现部分更新。 单一性 ：无论客户端连接哪个server，都会看到同一个视图。 可靠性：一旦数据更新成功，将一直保持，直到新的更新。 及时性：客户端会在一个确定的时间内得到最新的数据。 Zookeeper运用场景 数据发布与订阅 （我的业务用到这个特性，后面会有详细介绍） 应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。 名空间服务 分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。 分布式通知/协调 不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。 分布式锁 Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。 集群管理 每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。
常用命令的解释
ZooKeeper 常用四字命令： ZooKeeper 支持某些特定的四字命令字母与其的交互。它们大多是查询命令，用来获取 ZooKeeper 服务的当前状态及相关信息。用户在客户端可以通过 telnet 或 nc 向 ZooKeeper 提交相应的命令 1. 可以通过命令：echo stat|nc 127.0.0.1 2181 来查看哪个节点被选择作为follower或者leader 2. 使用echo ruok|nc 127.0.0.1 2181 测试是否启动了该Server，若回复imok表示已经启动。 3. echo dump| nc 127.0.0.1 2181 ,列出未经处理的会话和临时节点。 4. echo kill | nc 127.0.0.1 2181 ,关掉server 5. echo conf | nc 127.0.0.1 2181 ,输出相关服务配置的详细信息。 6. echo cons | nc 127.0.0.1 2181 ,列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。 7. echo envi |nc 127.0.0.1 2181 ,输出关于服务环境的详细信息（区别于 conf 命令）。 8. echo reqs | nc 127.0.0.1 2181 ,列出未经处理的请求。 9. echo wchs | nc 127.0.0.1 2181 ,列出服务器 watch 的详细信息。 10. echo wchc | nc 127.0.0.1 2181 ,通过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。 11. echo wchp | nc 127.0.0.1 2181 ,通过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。 1. 启动ZK服务: sh bin/zkServer.sh start 2. 查看ZK服务状态: sh bin/zkServer.sh status 3. 停止ZK服务: sh bin/zkServer.sh stop 4. 重启ZK服务: sh bin/zkServer.sh restart ############################################################
集群启动shell脚本
#!/bin/sh # crate file touch /opt/redis/zoo1/data/myid #write myid echo "1" >> /opt/redis/zoo1/data/myid echo "myid=" && cat /opt/redis/zoo1/data/myid #start zoo1 cd /opt/redis/zoo1/zookeeper-3.4.8 && bin/zkServer.sh start # crate file touch /opt/redis/zoo2/data/myid #write myid echo "2" >> /opt/redis/zoo2/data/myid #start zoo2 cd /opt/redis/zoo2/zookeeper-3.4.8 && bin/zkServer.sh start # crate file touch /opt/redis/zoo3/data/myid #write myid echo "3" >> /opt/redis/zoo3/data/myid #start zoo3 cd /opt/redis/zoo2/zookeeper-3.4.8 && bin/zkServer.sh start echo "启动完毕,查看启动状态" cd /opt/redis/zoo1/zookeeper-3.4.8 && bin/zkServer.sh status
集群停止的脚本
#!/bin/sh rm -rf /opt/redis/zoo1/data/myid #stop zoo1 cd /opt/redis/zoo1/zookeeper-3.4.8 && ./bin/zkServer.sh stop rm -rf /opt/redis/zoo2/data/myid #stop zoo2 cd /opt/redis/zoo2/zookeeper-3.4.8 && ./bin/zkServer.sh stop rm -rf /opt/redis/zoo3/data/myid #stop zoo3 cd /opt/redis/zoo2/zookeeper-3.4.8 && ./bin/zkServer.sh stop
