Zookeeper是一个开源的分布式协调框架，主要用来解决分布式集群中应用系统的一致性问题。从设计模式角度来理解其实zk是一个基于观察者模式设计的分布式服务管理框架。
CAP理论：
cap理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍处于一致的状态。
- 可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
- 分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性（Partition tolerance）这三项中的两项。
zookeeper保证的CP，eureka是AP ，redis是AP
BASE理论：
base是Basically Available(基本可用)、Soft-state(软状态)和Eventually Consistent（最终一致性）
- 基本可用：在分布式系统出现故障，允许损失部分可用性(服务降级、页面降级)
- 软状态：允许分布式系统出现中间状态，而且中间状态不影响系统的可用性，这里的中间状态是指不同的数据备份节点之间的数据更新可以出现延时的最终一致性。
- 最终一致性：数据备份节点之间经过一段时间达到一致性。
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
强一致性：任意时刻，所有节点中的数据是一样的，一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后才能正常对外提供服务；保证了强一致性，务必会损耗可用性。
弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值，即使过了不一致时间窗口，后续的读取也不一定能保证一致。
最终一致性：弱一致性的特殊形式，不保证在任意时刻任意节点上的同一份数据是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。
顺序一致性：任何一次读都能读到某个数据的最近一次写的数据。对其他节点之前的修改是可见且确定的，并且新的写入建立在已经达成同步的基础上。
Zookeeper写入是强一致性，读取是顺序一致性。
zk数据结构：
zk数据模型结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称作一个ZNode
zk数据模型是层次模型，层次模型和key-value模型是两种主流的数据模型，zk使用文件系统模型主要基于以下两点考虑：
- 文件系统的树形结构便于表达数据之间的层次关系
- 文件系统的树形结构便于为不同的应用分配独立的命名空间，每个节点都可以保存数据，每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识，每个节点都有一个版本，版本从0开始计数。
Zookeeper安装
zookeeper下载安装方式可以看这一篇文章：linux环境安装zookeeper(一)_酒书的博客-CSDN博客
在启动zk的时候如果报了这个错就是没有jdk环境，需要先装一下jdk环境，可以参考下面这篇文章
linux安装jdk和tomcat_酒书的博客-CSDN博客_linux 安装jdk和tomcat
有了jdk环境启动zk成功
通过命令查看zk状态bin/zkServer.sh status
然后启动zkClient连接zk server，使用命令bin/zkCli.sh -server ip:端口
zookeeper节点分类：
1、持久节点(PERSISTENT)：这样的znode在创建之后即使发生zk集群宕机或者client宕机也不会丢失。
2、临时节点(EPHEMERAL)：client宕机或者client在指定的timeout时间内没有给zk集群发消息，这样的znode就会消失。
3、持久顺序节点(PERSISTENT_SEQUENTIAL)：znode除了具备持久性znode的特点之外，znode的名字具备顺序性。
4、临时顺序节点(EPHEMERAL_SEQUENTIAL)：znode除了具备临时性znode的特点之外，znode的名字具备顺序性。
5、Container节点(3.5.3版本新增)：Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除(定时任务默认60s检查一次)。和持久节点的区别是zk服务端启动后，会有一个单独的线程去扫描所有的容器节点，当发现容器节点的子节点数量为0时，会自动删除该节点。可以用于leader或者锁场景中。
6、TTL节点：带过期时间节点，默认禁用，需要在zoo.cfg中添加extendedTypesEnabled=true开启，注意TTL不能用于临时节点
zookeeper节点特性总结
1、同一级节点key名称是唯一的
2、创建节点时，必须要带上全路径
3、session关闭，临时节点清除
4、watch机制，监听节点变化
事件监听机制类似于观察者模式，watch流程是客户端向服务端某个节点路径上注册一个watcher，同时客户端也会存储特定的watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。
5、delete命令只能一层一层删除。提示：新版本可以通过deleteall命令递归删除
