zk 笔记

高并发解决方案: lvs, nginx
 
分布式存储: HDFS, HBASE
 
建索引: luncens3, solor4, ES
 
计算框架:MapReduce, Spark
 
虚拟化: OpenStack KVM
        Docker  
        
资源分配: Yarn  
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
面试:当面试官知识体系比你宽时,给你薪资会比较客观
     因此需要反其道而行...
      
书籍:从paxos 到zookeeper
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Zookeeper 用途: 高可用(HA)
 
zookeeper 是google 的chubby 一个开源的实现
分布式应用程序可以基于它实现配置维护, 配置同步 和命名服务等.
 
zookeeper 是用来保证分布式应用数据一致性的.
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Paxos 是一个基于一个基于消息传递性的一致性算法, 被认为是唯一的分布式一致性算法.
* 半数以上通过,提议生效
* 只能投大于本地记录标号的提议
* 不能保证每个节点记录的编号总是相同的
* 投票并不看提议内容, 只看编号而已, 只要大于自己编号则同意
* 当大多数节点同意之后, 会向所有节点发送通知,更新本地编号
 
Paxos 算法冲突:
 
小岛 -- ZK server cluster
一员 -- zk node
提议 -- zk 数据改变
提议编号 -- zxid: zk transaction id
正式法令 --所有znode 及其数据
 
技术来源于生活...
+++++++++++++++++++++++++++++++++++++  2  ++++++++++++++++++++++++++++++++
 
* 查: 直接访问节点, 节点数据不一定是最新的,需要节点向主节点同步
* 主节点 宕机后, 从节点推选主节点, 谁先发请求协议,谁最有可能成为主节点.
 
 
zookeeper 角色
leader; 发起提议
follower: 投票
client: 查询,修改 CRUD
 
查询: client 直接请求follwer, follwer 向leader 请求同步
修改: client 请求follwer, follwer通知leader, leader 发起提议, 通过之后, 返回follwer, follwer返回client
 
 
why zk?
* 大部分分布式应用需要一个主控,协调器或控制器来管理物理分布的子进程
* 大部分应用需要开发私有的协调程序, 缺乏通用的机制
 
zk 提供通用的分布式锁服务,用以协调分布式应用:
对比keepalived 做HA
* keepalived 控制节点不好管理
* keepalived 采用优先级监控, 没有协同工作, 功能单一
* keepalived 可扩展性
ps: 通常keepalived 主从节点优先级设置相差50, 主宕机之后, 从节点马上接受, 当主重启之后,马上抢回主节点.
 
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
zk 特点
* 最终一致性: 客户端从每个节点中都能拿到相同的数据
* 可靠去:  
* 实时性: zk 不能保证两个节点之间数据一致, 如要获取最新数据, 在读数据之前需要调用sync 借口
* 独立性
* 原子性: 更新要不同时成功,要不同时失败,没有部分状态
* 顺序性: Leader 在单节点中
 
 
从节点推选为主节点看时机Timing
zk 工作原理
* 每个节点在内存中存储了一份数据, 定期落地到磁盘
* zk 启动时, 将从集群中选取一个leader
* leader 负责处理数据更新等操作
* 当超过半数更新成功时,则表示更新成功
 
zk 配置
* tickTime: 发送间隔时间单位毫秒
* dataDir: zk 保存数据目录
* clientPort: 占用端口
* initLimt: 几个tickTime 连接leader 无反应则证明连接失败
* syncLimit: leader 和 follower 直接发送消息,请求相应的应答长度, 单位ticktime
* server:
 
 
zk 安装配置:
1. 依赖java 环境
2. 和tomcat 类似, 都是apache的产品, 解压即可
3. 配置:新建zoo.cfg
4. 启动: zkServer.sh start
   状态: zkserver.sh status
    
 
++++++++++++++++++++++++++++++++++++  3  ++++++++++++++++++++++++++++++++++++++
zk 角色:  
leader: 负责进行投票的发起和决议,更新系统状态
learner:
    follower: 用于接受客户端请求,并向客户端返回结果,参与投票
    observer: 接受客户端连接,不参加投票过程,只同步leader 状态.类似于记者
              目的为了扩展系统,增长读性能
                
* 一般情况下, zk 集群为3, 5, 7, 9, 11 台,不会有太多, 因此也就么有太大必要扩展读的能力,所以observer 不常用.
* follower 节点越多, 选主,更新数据时通信比较频繁, 此时observer 更好
 
zk 核心是原子广播.实现这个机制的协议称为zab 协议, zab 协议有两种模式, 一种是回复模式(选主), 一种是广播模式(同步数据),
为保证事务一致性, zk采用了递增的zxid, zxid 为一个64位的数字. 高32 位标识leader 是否改变, 低32 位为数字,每次切换leader , 从0 开始记
 
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
zk 为什么要搭奇数台?
1. 容错性:
3台, 挂1台则集群垮了
4台, 挂1台则集群垮了, 与3台效果等价
 
2. 防止出现脑裂情况出现(主)
  都是半数节点时, 选不出主节点, 则集群不能正常工作
 
   
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
zookeeper 本身是高可用的, 是维护自己本身高可用的
 
zk命令:
* ls: 查看数据节点
* create /path  data: 创建数据节点   
 
+++++++++++++++++++++++++++++++++++++++++++++++++++  5  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Znode 数据有两种类型: 短暂的(ephemeral) 和 持久的(persistent)
短暂的: client 连接时创建, 断开连接时销毁, 类似于session
 
四种节点类型
* ephemeral
* persistent
* ephemeral_sequence
* persistent_sequence: 名字会加序号标识
 
 
zk API:
api 很简单,数量也少, 只有一个zookeeper 类
使用API时,如果没有父节点,直接创建子节点会报错
 
zk 一般用在内网中,管理集群配置.
 
 
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
zk 高可用: 被动接受注册, 每个server 启动时向zk 注册, cli 直接访问zk
keepalived: 主动监测server状态
 
 
Watcher:是zk 的一个核心功能, 可以监控目录节点的数据变化及子目录的变化, 一旦发生变化,服务器就会通知所有记录节点的Watcher, 从而每个客户端就很快能知道它所关注的目录节点的状态发生变化,而做出相应改变.
 
 
dubbo 做高可用的框架, 依赖于zk
 
zk 是一个比较底层的东西, 很多框架都都用它来做高可用
 
 
** watcher 只发送一次, 接收到应该重新注册 **