Zookeeper
是一个分布式应用程序提供高性能协调服务的工具集合。
ZooKeeper本质上是一个分布式的小文件存储系统。原本是Apache Hadoop的一个组件，现在被拆分为一个Hadoop的独立子项目，在HBase（Hadoop的另外一个被拆分出来的子项目，用于分布式环境下的超大数据量的DBMS）中也用到了ZooKeeper集群。
Hadoop，使用Zookeeper的事件处理确保整个集群只有一个NameNode，存储配置信息等.
HBase，使用Zookeeper的事件处理确保整个集群只有一个HMaster，察觉HRegionServer联机和宕(dàng)机，存储访问控制列表等。
ZooKeeper节点Znode
ZooKeeper目录树中每一个节点对应一个Znode。每个Znode维护着一个属性结构，它包含着版本号(dataVersion)，时间戳(ctime,mtime)等状态信息。ZooKeeper正是使用节点的这些特性来实现它的某些特定功能。每当Znode的数据改变时，他相应的版本号将会增加。每当客户端检索数据时，它将同时检索数据的版本号。并且如果一个客户端执行了某个节点的更新或删除操作，他也必须提供要被操作的数据版本号。如果所提供的数据版本号与实际不匹配，那么这个操作将会失败。
Znode是客户端访问ZooKeeper的主要实体，它包含以下几个特征：
（1）Watches
客户端可以在节点上设置watch(我们称之为监视器)。当节点状态发生改变时(数据的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次。
（2）数据访问
ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
（3）节点类型
ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
ZooKeeper的临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。另外，需要注意是，ZooKeeper的临时节点不允许拥有子节点。
ZooKeeper的永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
（4）顺序节点（唯一性的保证）
当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的，它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。当计数值大于232-1时，计数器将溢出。
org.apache.zookeeper.CreateMode中定义了四种节点类型，分别对应：
PERSISTENT：永久节点
EPHEMERAL：临时节点
PERSISTENT_SEQUENTIAL：永久节点、序列化
EPHEMERAL_SEQUENTIAL：临时节点、序列化
ZooKeeper数据模型
ZooKeeper拥有一个层次的命名空间，这个和分布式的文件系统非常相似。不同的是ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子znode。用户对znode具有增、删、改、查等操作（权限允许的情况下）。
znode具有原子性操作，每个znode的数据将被原子性地读写，读操作会读取与znode相关的所有数据，写操作会一次性替换所有数据。zookeeper并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。zooKeeper的服务器和客户端都被设计为严格检查并限制每个znode的数据大小至多1M，当时常规使用中应该远小于此值。
Zonde由路径标注，ZooKeeper中被表示成有反斜杠分割的Unicode字符串，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由反斜杠来字符开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。ZooKeeper的数据结构,与普通的文件系统极为类似.
图中的每个节点称为一个znode.每个znode由3部分组成:
1.stat：此为状态信息,描述该znode的版本,权限等信息.
2.data：与该znode关联的数据.
3.children：该znode下的子节点.
ZooKeeper部署-单机模式
zoo.cfg配置
重要命令
[hadoop@centos-1 zookeeper-3.4.5-cdh4.3.0]$bin/./zkServer.sh start
JMX enabled by default
Using config:/export/home/tools/zookeeper-3.4.5-cdh4.3.0/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
[hadoop@centos-2 zookeeper-3.4.5-cdh4.3.0]$bin/./zkServer.sh status
JMX enabled by default
Using config: /export/home/tools/zookeeper-3.4.5-cdh4.3.0/bin/../conf/zoo.cfg
Mode: standalone
[hadoop@centos-1 zookeeper-3.4.5-cdh4.3.0]$bin/./zkServer.sh start
JMX enabled by default
Using config:/export/home/tools/zookeeper-3.4.5-cdh4.3.0/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
[hadoop@centos-2 zookeeper-3.4.5-cdh4.3.0]$bin/./zkServer.sh status
JMX enabled by default
Using config:/export/home/tools/zookeeper-3.4.5-cdh4.3.0/bin/../conf/zoo.cfg
Mode: leader
[hadoop@centos-2 zookeeper-3.4.5-cdh4.3.0]$bin/./zkServer.sh status
JMX enabled by default
Using config:/export/home/tools/zookeeper-3.4.5-cdh4.3.0/bin/../conf/zoo.cfg
Mode: follower
Zookeeper使用场景
分布式独占锁
分布式读写锁
分布式队列-FIFO
分布式队列-SyncQueue
默认值递增
安装mvn
1、获取代码
#git clonehttps://github.com/DeemOpen/zkui.git
2、构建并安装程序
#cd zkui/
#yum install -y maven
#mvn clean install
3、修改配置文件
#cp config.cfg target/
#cd target/
#vim config.cfg
serverPort=9090 #指定端口
zkServer=xxxx:2181,xxxx:2181
userSet = {"users": [{ "username":"admin" , "password":"admin","role": "ADMIN" },{ "username":"appconfig" , "password":"appconfig","role": "USER" }]}
4、启动程序至后台
#nohup java -jar zkui-2.0-SNAPSHOT-jar-with-dependencies.jar &
5、用浏览器访问
http://xxxx:9090
6、Kafka
kafka是由LinkedIn开发，主要是用来处理Linkedin的大面积活跃数据流处理(activitystream).此类的数据经常用来反映网站的一些有用的信息，比如PV,页面展示给哪些用户访问，用户搜索什么关键字最多，这类信息经常被log到文件里，然后线下且周期性的去分析这些数据。现在这种用户活跃数据已经成为互联网公司重要的一部分，所以必须构建一个更轻量且更精炼的基础架构。
√活跃数据使用案列
分析一下用户行为（pageviews），以便我能设计出更好的广告位。
快速的统计用户投票，点击。
对用户的搜索关键词进行统计，分析出当前的流行趋势。
防止用户对网站进行无限制的抓取数据，以及超限制的使用API,辨别垃圾。
对网站进行全方位的实时监控，从而得到实时有效的性能数据，并且及时的发成警告。
批量的导入数据到数据仓库，对数据进行离线分析，从而得到有价值的商业信息。(0.6可以直接将数据导入Hadoop)
√活跃数据的特点
高流量的活跃数据是无法确定其大小的，因为他可能随时的变化，比如商家可能促销，节假日打折，突然又冒出一个跳楼价等等。所有的数据可能是数量级的往上递增。传统日志分析方式都是需要离线，而且操作起来比较复杂，根本无法满足实时的分析。另一方面，现有的消息队列系统只能达到近似实时的分析，因为无法消费大量的持久化在队列系统上的信息。Kafka的目标就是能够成为一个高效的队列平台，无论是处理离线的信息还是在线的信息。
Kafka集群
消息存储设计
设计特点
消息保存在磁盘，O(1)时间复杂度
不使用内存？使用磁盘缓存
消费状态保存在消费客户端
可以保存足够大的未处理消息
