Zookeeper（一）初识
概述
美团，饿了么，淘宝，58同城等等应用都是zookeeper的现实生活版
我开了个饭店，如何才能让大家都能吃到我们的饭菜？需要入驻美团，这样大家就可以在美团app中看到我的饭店，下订单，从而完成一次交易
Zookeeper是一个开源的分布式（多台服务器干一件事）的，为分布式应用提供协调服务的Apache项目。
在大数据技术生态圈中，zookeeper（动物管理员），Hadoop（大象），Hive（蜜蜂），Pig（猪）等技术
工作机制
Zookeeper从设计模式角度来理解：是一个基于观察者模式（一个人干活，有人盯着他）设计的分布式服务管理框架
它负责 存储 和 管理 大家都关心的数据
然后接受观察者的注册，一旦这些数据的发生变化
Zookeeper就将负责通知已经注册的那些观察者做出相应的反应
从而实现集群中类似Master/Slave管理模式
Zookeeper = 文件系统 + 通知机制
- 商家营业并入驻
- 获取到当前营业的饭店列表
- 服务器节点下线
- 服务器节点上下线事件通知
- 重新再去获取服务器列表，并注册监听
特点
分布式和集群的区别？
无论分布式和集群，都是很多人在做事情。具体区别如下：
例如：我有一个饭店，越来越火爆，我得多招聘一些工作人员
分布式：招聘1个厨师，1个服务员，1个前台，三个人负责的工作不一样，但是最终目的都是为饭店工作
集群：招聘3个服务员，3个人的工作一样
- 是一个leader（头）和多个follower（随从）来组成的集群（狮群中，一头雄狮，N头母狮）
- 集群中只要有半数以上的节点存活，Zookeeper就能正常工作（5台服务器挂2台，没问题；4台服务器挂2台，就停止）【一般选择奇数台服务器，1、3、5…】
- 全局数据一致性，每台服务器都保存一份相同的数据副本，无论client连接哪台server，数据都是一致的
- 数据更新原子性，一次数据要么成功，要么失败（不成功便成仁）【强一致性】
- 实时性，在一定时间范围内，client能读取到最新数据
- 更新的请求按照顺序执行，会按照发送过来的顺序，逐一执行（发来123，执行123，而不是321或者别的）
数据结构
ZooKeeper数据模型的结构与linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode（ZookeeperNode【Zookeeper节点】）。
每一个ZNode默认能够存储1MB的数据（元数据），每个ZNode的路径都是唯一的
元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能
应用场景
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等
统一命名服务
在分布式环境下，通常需要对应用或服务进行统一的命名，便于识别
例如：服务器的IP地址不容易记，但域名相比之下却是很容易记住
统一配置管理
分布式环境下，配置文件做同步是必经之路
1000台服务器，如果配置文件作出修改，那一台一台的修改，运维人员肯定会疯，如何做到修改一处就快速同步到每台服务器上
将配置管理交给Zookeeper
1、将配置信息写入到Zookeeper的某个节点上
2、每个客户端都监听这个节点
3、一旦节点中的数据文件被修改，Zookeeper这个话匣子就会通知每台客户端服务器
就好像农村里面，发生一点事情，告诉一个喜欢说话的人，差不多全村人都晓得了
服务器节点动态上下线
客户端能实时获取服务器上下线的变化
在美团APP上实时可以看到商家是否正在营业或打样
软负载均衡
Zookeeper会记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户请求（雨露均沾）
都是自己的孩子，得一碗水端平
