6.1 Zookeeper

历史背景

-所有的的计算任务都由一台计算机完成，数据的存储也由一台计算机完成

-单节点计算
	-单点故障
	-性能瓶颈
		-IO的瓶颈
		-内存

数据存储的方式

-将数据存放在多块磁盘肯定能解决IO瓶颈的问题

-全量备份
	-好处：有效的缓解了IO的问题
	-缺点：不利于数据的扩充
	
-对数据进行切片shard
	-好处 ：
		-有效的缓解了IO的问题
		-还可以更多的去存放数据，容量可以扩充
	-缺点：
		-当一个节点异常关闭
		-所有的数据都失效
		
-Raid
	-RAID 的基本思想是将多个容量较小、相对廉价的磁盘进行有机组合，从而以较低的成本获得与昂贵大容量磁盘相当的容量、性能、可靠性
	
-Hadoop
	-综合了全量备份与切片备份
	-每一份都有三个数据

数据的一致性

-强一致性
	-假如更新一次数据，所有的存储节点都要更新数据
	-而且必须等待所有的节点更新完成才能继续进行读写操作
	-写入数据的时候节点被锁定，数据不能被读取

-弱一致性
	-读取数据的时候，不需要是最新的，只要能读到就行
	
-顺序一致性
	-任何一次读都能读到某个数据的最近一次写的数据。
	-系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对
	-总结
		-执行速度快于强一致性
		-有可能所有进程得到的都是修改前的数据
		
-最终一致性
	-我们只需要超过半数以上的用户拿到正确数据即可
	-身份
		-皇帝
			-领导者
		-大臣
			-数据的投票者
	-固定的人数
		-3000
	-法令生效
		-超过半数人的同意（已经更新了数据）

-最终一致性的研究
	-无主，有主
		-有主
			-只能有一个主发送指令
			-单主会单点故障
			-如果存在多个主就会脑裂
		-无主
			-人人都会发送指令,投票
			-投票人数有可能导致分区(分不同阵营)
		-从无主中选有主
			-为什么集群的数目往往是单数
			-3（1）4（1）5（2）6（2）
		-角色的分配
			-looking
			-Observer
			-Follower
			-Leader

CAP原则

-鱼与熊掌不可兼得原则

-指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

-CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

Paxos

-Paxos
	-小岛(Island)
	-议员(Senator)
	-议员的总数(Senator Count)是确定的
	-提议(Proposal),每个提议都有一个编号(PID)，这个编号是一直增长的
	-每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效
	-每个议员只会同意大于当前编号的提议
	-每个议员在自己记事本上面记录的编号，他不断更新这个编号
	-整个议会不能保证所有议员记事本上的编号总是相同的
	-议会有一个目标：保证所有的议员对于提议都能达成一致的看法。

-前期投票(>1/2)，后期广播(all)

Zookeeper

-ZK Server Cluster

-总统——ZK Server Leader
	-集群中所有写数据的指令必须由总统发出
	-总统是由议员投票产生的
	
-议员(Senator)——ZK Server
	-接受客户端请求，
		-查询直接返回结果（有可能数据不一致）
		-写入数据，先将数据写入到当前server
			-发送消息给总统，总统将修改数据的命令发送给其他server
			-其他server接受命令后开始修改数据，修改完成后给总统返回成功的消息
			-当总统发现超过半数的人都修改成功，就认为修改成功了
			-并将信息传递给接受请求的zkServer,zkServer将消息返回给客户端，说明数据更新完成
			
-提议(Proposal)——ZNode Change
	-客户端的提议会被封装成一个节点挂载到一个Zookeeper维护的目录树上面
	-我们可以对数据进行访问（绝对路径）
	-数据量不能超过1M
	
-提议编号(PID)——Zxid
	-会按照数字序列递增，不会减少不会重复
	
-正式法令——所有ZNode及其数据
	-超过半数的人将数据更新这个数据，就说明数据已经是正式的了
	
-屁民--Client
	-发送请求（查询请求，修改请求）

原语

-计算机的逻辑概念，指一个不可再分的操作单元，要么完成，要么失败
-原语一旦开始执行，就要连续执行完，不允许中断
-一旦不会让开发人员操作，只会暴露一些操作的接口

配置文件

搭建Zookeeper环境

-基于Observer的环境搭建

-Zookeeper的热部署

选举Leader的条件

-首先按照事务zxid进行排序

-如果事务相同按照myid排序

操作Zookeeper

zookeeper的 bin目录中
输入:
zkCli.sh
进入zookeeper命令行窗口模式

-以keyvalue的方式存在

-以树状结构管理数据，既是目录还是数据的key

-所有的数据访问都必须以绝对路径的方式呈现

-[zk: localhost:2181(CONNECTED) 10] get /shsxt
big 当前节点的值
cZxid = 0xf00000013 创建这个节点的事务id
ctime = Mon Dec 09 17:33:06 CST 2019 创建时间
mZxid = 0xf00000013 最后一次修改节点数据的事务ID
mtime = Mon Dec 09 17:33:06 CST 2019 修改时间
pZxid = 0xf00000014 子节点的最新事务ID
cversion = 1 数据的版本
dataVersion = 0 
aclVersion = 0
ephemeralOwner = 0x0 （持久化节点）0x16ee9fc0feb0001（临时节点）
dataLength = 3 数据的长度
numChildren = 1 子节点的数目

-节点的分类
	-临时节点
		-只要创建节点的会话有效，节点就不会失效
		-可以被所有的客户端所查看
	-持久化节点（PERSISTENT）
		-默认创建的就是持久化节点
	-序列化节点
		-在名字的后面添加一个序列号(有序)