zookeeper

为什么用zk做分布式协调服务

1.leader肯定会挂
2.服务不可用
3.zk可以快速选主，并且瞬间能提高到挂掉之前的状态

zk目录结构

1.zookeeper是一个目录树结构
2.node可以存储数据，最大1MB
3.分为临时节点、持久节点、序列临时节点、序列持久节点、client连接先连接session,通过session操作zk
  

zk特征

1.顺序一致性。 客户端额更新将按发顺序应用。
2.原子性。 更新成功或者更新失败，没有中间状态。
3.统一视图。无论连接那个服务器，客户端都会看到相同的视图。
4.可靠性。官方压测910个clinet，每秒4W次，故意让zk中间挂了两次，zk能在200毫秒内恢复，且能瞬间达到挂机之前的状态
5.及时性。

zookeeper选主原理 -- 使用了paxos算法

https://www.douban.com/note/208430424/

zk创建节点流程

1.原子性，只有成功或失败，没有中间状态
2.都先给自己投一票，然后将这件事广播出去，给每一台节点，过半通过
3.投票给比自己事务id(zxid)大的，
4.zxid一样，选择myid大的

创建流程
1.clinet连接follower节点发起create /xiaoke 目录
2.follower将这个请求发给主节点，主节点回复ok
3.主节点将这个请求放进队列中，然后广播出去
4.开始投票，过半写入，
5.创建目录、写日志、告诉client创建ok

zookeeper面试题：

https://www.cnblogs.com/Fairy-02-11/p/14439612.html

补充

1.端口:
3888 follow用来选主
2888 leader接口write请求
2181 客户端连接

2.节点存储数据最大1MB

3.为什么zk选主这么快
　　a.官网压测数据显示，910个client，每秒4W次，故意让zookeeper中间挂了两次，zookeeper能在200毫秒内回复，且能瞬间达到挂机之前的状态
　　b.每个follow节点开始投票，投票给事务zxid最大的一票，当票数一样，对比谁的myid最大。 比起其他集群，如果票数一样多，就会重新投票。

CAP理论

    一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
    可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
    分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
    在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。

zk抢锁

1、争抢锁，只有一个人能获得锁。
2、获得锁的人出问题，临时节点(session)
3、获得锁的人成功了,释放锁。
4、锁备释放、删除、别人怎么知道的?
    a、主动轮训，心跳   弊端: 延迟，压力(当抢锁的人多的时候)
    b、watch： 解决延迟问题   弊端:压力(当抢夺的人多的时候，大家都watch这一个锁，当这个锁一释放，大家都去抢资源)
    c、sequence + watch ：watch前一个，一旦霸占锁的释放了，只有watch的这一个去抢，其他的继续watch前一个， 成本：zk只给第二个发时间回调。