zookeeper
为什么需要zookeeper
对于多线程的弊端，看下图
由于多线程的运行比较难，所以把线程换成进程，相当于每台服务器上跑一个程序，相同的程序运行在多个服务器集群上，是为了解决单台服务器面对高并发处理不过来的情况
但是对于集群又会出现一些新的问题
- 多台服务器一个集群，如何保证所有机器共享的配置信息一致
- 有一台服务器挂掉了，其他机器如何感知
- 用户量突然暴增，需要新增机器缓解压力，如何做到不重启集群完成机器的添加
- 分布式系统，怎么高效协同多台服务对同一网络文件进行写操作
因此需要一个能让各个程序进行协同的工具 zookeeper应运而生
zookeeper介绍
zookeeper是一个分布式服务协调组件，这个命名翻译过来是动物园管理员，主要是因为其管理的一些分布式的项目，如Hadoop(大象)、Hive(蜜蜂)、Pig(猪)等，为分布式应用提供了一种高性能协调服务，特点是数据存于内存中的，持久化实现在日志中。它的内存类似于树形结构，且高吞吐低延迟。
组成zookeeper服务的服务器必须彼此了解，它们维护内存中的状态图像，以及持久化存储中的事务日志和快照。
客户端连接到单个zookeeper服务器，客户端维护TCP连接，通过该连接发送请求，获取响应，获取监听事件以及发送tick。如果服务器的TCP连接中断，则客户端将连接到其他服务器。
zookeeper可以做什么
- 主要用于分布式系统，可以用zookeeper做统一配置管理、统一命名服务、分布式锁、集群管理。
- 使用分布式系统对节点管理
zookeeper数据结构
Zookeeper内部结构与Unix文件系统类似，可以看做是一棵树，以”/“为根节点，每个节点叫做ZNode，每个节点可以通过路径来标识，每个ZNode默认能够存储1M的数据，ZNode中包含了数据data、子节点引用child、访问权限acl、元数据stat(如事务id、版本号、时间戳、大小等)等
znode类型
- 短暂/临时（Ephemeral）节点：客户端与服务端之间采用长连接的方式进行通信，并通过心跳来保持连接，这个连接状态称为session，当客户端和服务器断开连接后，所创建的Znode会自动删除（临时节点不能挂子节点，只有永久节点才可以）
- 持久（Persistent）节点：当客户端和服务器断开连接后，所创建的Znode不会删除，除非显式删除，否则一直存在
- 无序（Non-sequence）节点：多个客户端同时创建同一个无序节点时，只有一个可以创建成功，其他均失败，且节点名字与指定名完全相同
- 有序（Sequence）节点：创建出的节点名在指定名称之后带有10位10进制的序号，多个客户端创建同一名称节点时，都能成功，只是序号不同
Znode包含ACL权限控制、修改/访问时间、最后一次操作的事务id（zxid）等
zookeeper的特点
- zookeeper是由一个领导者(Leader)，多个跟随者(Follower)组成的集群
- 集群中只要有半数以上节点存活，zookeeper集群就可以正常工作
- 原子性 要么集群中所有机器都成功的处理了某个请求，要么就都没处理，没有部分结果
- 有序（顺序一致性）
zookeeper给每个更新赋予一个为一个时间戳zxid，这个数字反映了所有zookeeper事务的顺序- Zxid：zookeeper中每次写请求都对应一个唯一的事务id，称为Zxid，它是全局有序的，如果Zxid1小于Zxid2，那么Zxid1一定会发生在Zxid2前
- version numbers：版本号，对节点的写请求都会导致该节点的3种版本号增加 dataVersion（对znode数据的更改次数）， cversion（对znode子节点的更改次数），aclversion（对znode ACL的更改次数）
- ticks：当使用多服务器zookeeper时，服务器使用一个”滴答”来定义事件的时间，如状态上传，会话超时等，通过最小会话超时时间（默认是滴答事件*2）间接公开，如果客户端请求超过这个时间，那客户端就不能再连接上服务器端
- 全局数据一致，zookeeper是CP模型，在一致性和可用性中选择了一致性，每个Server都会保存一份相同的数据副本，无论连接到哪个服务器，客户端都可看到相同的内容。这也使得Leader将数据同步给所有Follower后，整个zookeeper集群才会对外提供服务
- 可靠性 一旦服务端数据状态发生了变化，就会立即存储起来，除非此时有另一个请求对其进行了修改
- 及时性 保证系统的客户端当时读取到的数据是最新的
zookeeper拥有的功能
监视节点、通知进程、保持长连接、会话延续