zookeeper是很早的注册中心，在我刚毕业的时候，就已经开始开始。一种分布式协调服务，使用简单的API和架构决绝了这个问题。
2、zookeeper的应用场景分布式协调组件，协调分布式场景下各个组件的状态分布式锁，因为zookeeper是符合cp的，所以分布式锁相对redis更安全无状态化的实现，存放登录状态 二、搭建zookeeper服务器 1、zoo.cfg配置文件说明
# zk时间配置中的基本单位（毫秒） tickTime=2000 # 允许follower初始化链接到leader最大时长，它表示tickTime时间陪数：initLimit* tickTime initLimit=10 # 允许follower与leader数据同步最大时长 syncLimit=5 # zk数据存储目录及日志保存目录（没指名日志目录，也保存在这个地址） dataDir=/tmp/zookeeper dataLogDir=/tmp/zookeeper/log # 对客户端提供的端口号 clientPort=2181 # 单个客户端与zk最大并发连接数 maxClientCnxns=60 # 保存数据快照数量，之外的会被清除 autopurge.snapRetainCount=3 # 自动触发清楚任务间隔时间，默认为0 表示不清除 autopurge.purgeInterval=12、zookeeper服务器操作命令
./zkServer.sh stopstatusstart. 关闭、状态、启动./zkCli.sh 客户端链接命令 三、zookeeper内部的数据模型 1、zookeeper是如何保存数据的
zk是可以存放数据的，数据都是保存在znode上，是以树状结构存放相关数据的：
获取数据：
那么说明，数据abc存放在test2这个znode中。
2、zookeeper中znode是什么样结构zk中的znode，包含四个部分：
data：保存数据acl：权限
c：create权限，允许在节点下创建子节点w：write权限，允许更新该节点的数据r：read权限，允许读取该节点的内容及子节点的列表信息d：delete权限，允许删除该节点的子节点a：admin权限，允许对该节点进行acl权限设置stat：表述当前znode的元数据child：当前节点的子节点
3、zookeeper中节点znode的类型持久节点：创建出的节点，在回话结束后，依然存在，并能保存数据持久序号节点：创建出的节点，根据先后顺序，会在节点以后带上递增序列，适用于分布式锁、高并发场景（create -s /test01）临时节点：临时节点是在回话结束后，自动被删除的，通过这个特性，zk可以实现服务发现和注册的效果（create -e /test01）临时序号节点：跟持久序号节点相同，只不过是临时的（create -e -s /test01）Container节点：容器节点，当容器中没有任何子节点的时候，会被zk定期删除（60s）(create -c /test01)TTL节点：指定节点到期时间，到期后会被zk定时删除，需要设置才能开启
临时节点删除流程：
4、zookeeper的数据持久化zk的数据是运行在内存中的，必然会提供持久化机制，zk提供的持久化有2种：
事物日志：zk把执行的命令以日志的形式保存在文件中数据快照：zk会定期对内存数据做一次快照并保存到本地硬盘中
同redis一样，采用混合方式进行恢复，先用快照恢复，然后用事物日志增量恢复。
四、zookeeper客户端的使用（zkCli） 1、多节点类型的创建 2、查询节点查询普通节点查询节点相信信息
zCxid：创建节点的事务IDmZxid：修改节点的事务IDpZxid：添加和删除子节点的事务IDctime：节点创建的时间mtime：节点最近修改的时间dataVersion：节点的数据版本，每次修改都会+1aclVersion：节点的权限版本ephemeralOwner：临时节点的sessioIddataLength：数据长度numChildren：子节点个数 3、删除节点
delete -v 1 /test1 删除数据版本为1的test1节点（乐观锁） 4、权限设置
- 注册当前回话的账号密码：addauth digest xiaowang:123456创建节点并设置权限：create /test-node abcd auth:xiaowang:123456:cdwra在另一个回话，必须使用账号密码，才能操作该节点
Curator是一个zk客户端，NetFlix提供的客户端。同时也封装了很多功能，比如Leader选举、分布式锁等等，减少了java开发人员使用zk时候底层细节开发工作。也被称为最好的zk开源框架。
pom：
六、zookeeper实现分布式锁 1、zk中锁的种类读锁：大家都读，想要上读锁的之前，之前的锁没有写锁写锁：只有得到锁的才能写。想要上写锁之前，是没有任何锁 2、zk如何上读锁
创建一个临时序号节点，节点的数据是read，表示读锁获取当前zk中序号比自己小的所有节点判断最小节点是否是读锁：
如果不是读锁，则上锁失败，为最小节点设置监听。阻塞等待，zk的watch机制会当最小节点发生变化的时候，通知当前节点，在执行第二步如果是读锁的话，则上锁成功 3、zk如何上写锁
创建一个临时序号节点，节点的数据是wirte，表示写锁获取zk中全部的子节点判断自己是否是最小的节点：
如果是，则上写锁成功如果不是，则说明前面还有锁，则上锁失败，监听最小的节点，如果最小节点有变化，则回到第二步 4、羊群效应
如果使用上述的上锁方式，只要节点发生变化，就会出发其他节点的监听事件，这样的话对zk的压力很大，也就是羊群效应，使用链式监听可以解决这个问题。
七、zookeeper的watch机制 1、watch机制介绍我们可以把watch理解成是注册在特定Znode上的触发器。当这个Znode改变了，也就是调用create、delete、setData方法的时候，就会将触发Znode上注册的对应事件，请求watch的客户端就会接收到异步通知。客户端使用NIOfang s
交互如下：
客户端调用getData方法，wathc参数是true。服务端接到请求，返回节点数据，并在对应hash表中插入被watch的Znode路径，以及wathc列表当watch的znode被删除，服务端会查找hash表，异步通知所有的watcher，并删除hash表中的数据。
使用ls -w 监听目录变化。get -w 是监听节点内容的。-R 递归监听。
八、zookeeper集群实战 1、zk集群中的角色zk集群中有三种角色：
Leader：处理集群所有事务，集群中只有一个leaderFollower：只能处理请求，参与Leader的选举Observer：只能处理读请求，提升集性能，不参与Leader的选举 2、搭建集群
- 准备四个节点的数据
- 创建每个节点的myId描述文件创建每个节点的zoo.cfg文件创建节点之间的通信，第一个端口是数据通信、第二个端口是集群leader选举的
./zkCli.sh IP1:port IP2:port 九、ZAB协议 1、ZAB介绍
zk作为非常重要的分布式协调组件，集群会以一主多从的形式进行部署。zk是强数据一致性的（CP），所以用到了ZAB（原子广播协议）协议，zk节点崩溃的时候，主从同步问题。
2、ZAB协议四种节点的状态Looking：选举状态Following：Follower节点状态Leading：Leader节点状态Observeing：观察者节点状态 3、集群上线时的Leader选举过程
- 第一个、第二个节点启动完成后，就开始了集群选举比较事物ID和MyID，以事物ID优先。所以第一轮就是第二个节点胜出（因为 都没有事物）因为得票数没有超过集群的一半，第二轮选举，都会投票给上一轮成功的，同时也是node1和node2进行选举 当node3启动后，发现已经选举完毕，自己直接就称为了follower其实前两个节点的时候，已经知道集群有三个节点了，因为配置文件已经放入了所以zk需要奇数节点
当leader宕机的时候，follower节点发现，会重新选举新的leader。此时集群不对外提供服务。
5、主从服务器之间的数据同步主节点负责全部的写操作主节点把数据写到自己的数据文件中，并返回一个ACK主节点把数据发送给从节点（广播）从节点写入到本地数据文件中从节点返回ACK给主节点主节点接收到半数以上的ACK后向从节点发送Commit从节点收到Commit后，把数据写入到内存中
也就是zk为什么是CP的，必须半数以上的节点已经写入的文件中，才向内存提交。
6、zk中的NIO和BIO应用NIO（现在已经是netty了）
用于客户端链接2181端口客户端开启Watch时候，也是用NIOBIO
在选举投票，多节点直接通信的时候，使用BIO 十、CAP理论 1、CAP定理
一个分布式系统中最多只能同时满足一致性（C）、可用性（A）和分区容错性（P）中的2项：
一致性（Consistency）：一致性是指更新操并返回客户端后，所有节点统一时间的数据一直可用性（Availability）：可用性是指服务一直可用，而且是正常响应时间分区容错性（Partition tolerance）：分布式系统在遇到某个节点或者网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务 2、CAP权衡
既然无法同时满足CAP，那么需要社区哪个呢 ？
在分布式系统中，分区容错性一定是要满足的，否则整个系统就不存在意义。
一致性和可用性，一致性追求的就是数据的就一致性，可用性追求的就是系统在任何时候都是可用的。两个属性是相互违背的。
如果为了数据一致性，在数据同步的时候，是否对外提供服务就是一个大问题，如果提供服务，那么就会出现错误数据的访问，如果不提供服务，那么就无法满足可用性。
3、base理论base理论是对CAP理论的眼神，核心思想是无法做到强一致性（CAP就是强一致性），但是可以采用合适的方法达到最终一致性。
基本可用：基本可用性是指分布式系统在出现故障的时候，允许损失部分可用性，既保证核心可用。软状态：软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少会有三个副本，允许副本延迟同步就是软状态的表现。最终一致性：最终一致性是指系统中所有数据副本在经过一定时间之后，最终能够达到一致的状态。是弱一致性的一直特殊状态 4、zk追求的一致性
zk在追求过程主，满足的是CP，也就是满足数据一致性，最大的特点当复制同步的数据时候，只有半数以上的数据完成本地文件存储，才能同时写入内存。但是也不是强一致性，追求的算是顺序一致性。
