- Zoookeeper
- 提供分布式系统中分布式协同服务
- Leader/Follwer/observer
- 1.follower接收到客户端发送过来的写请求后，会把该写请求转发给leader处理
- 2.leader接收到follower发送过来的写请求后，会转换成带有各种状态的事务，会把事务进行广播
- 3.所有接收到proposal的follower就要进行投票，都需要向leader返回ACK
- 4.发送事务提交请求
- observer不参与选举
- zk默认端口2181
- watcher（事件监听器），特定事件的监听
- 持久性节点：一直存在
- 临时性节点：会被自动清理，和客户端会话绑定
- 顺序性节点：加一个后缀表示顺序
- 事务ID（ZXID：64位数字）
- watcher实现分布式监听
- zookeeper开源客户端zkclient
- 有超时重连和事件注册功能
- 可以递归创建节点
- zkclient可以对不存在的节点监听
- Curator客户端。提供了fluent风格
- 基于zk的两大特性对集群机器监控
- 1.订阅通知
- 2.临时节点的会话生命周期
- 集群管理：日志系统用zk
- 1.注册收集器机器
- 2.任务分发
- 3.状态汇报
- 4动态分配
- 如果收集器挂掉或者扩容，重新分配
- 4.1全局动态分配
- 4.2局部动态分配：收集器汇报负载，把挂掉的节点转移给负载低的收集器
- master选举
- 1.所有节点向数据库插入同一主键id，成功的就是master
- 2.zk创建同一临时节点，成功就是master，其他客户端在父节点注册节点变更事件
- zk分布式锁
- 1排他锁
- 只允许持有锁操作，只有一个事务获得锁
- 1.1创建一个临时节点锁
- 1.2只有创建成功了的获取锁，其他注册监听事件
- 1.3释放锁：当执行完主动释放，节点挂掉自动释放
- 2.共享锁
- 数据对所有事务可见
- 2.1创建临时顺序节点
- 2.2读写请求区分，创建顺序节点后对父节点变更监听
-
对于读请求，如果没有比自己序号小的子节点或者比自己小的节点都是读请求 - 可以成功获取锁
-
对于写请求，如果自己不是序号最小的写节点，需要等待 - 接到事件变更通知后，重复校验步骤
- 2.3释放锁
- 羊群效应
- 如果集群规模大，重复大量的watcher通知，对zk集群造成巨大开销
- 可以只注册前面一个节点的监听事件，不在父节点
- 读请求监听前面的最后一个写请求，写请求监听前面一个节点
- 分布式队列
- 临时顺序节点
- 分布式屏障(barrier)
- ZAB协议:不完全是paxos算法
- 核心是定义改变zk服务器数据状态的事务请求的处理方式
- 崩溃恢复模式：ZAB协议保证事务可以在所有服务器上都能提交成功保证事务一致性
- 消息广播模式：类似二阶段提交，超过半数follower就广播commit
- ZAB与paxos
- 相同
- 1。都存在leader进程
- 2.都会超过半数follower反馈才会提交
- 3.有leader周期
- 不同
- 服务器角色
- leader:
- 事务请求的调度者和处理者。集群内部服务器的调度者
- follower:
- 处理非事务请求，转发事务请求给leader
- 参与proposal投票
- 参与leader选举
- observer：
- 工作原理和follower基本一致，只是不参与投票
