ZooKeeper-学习日志-20181214

ZooKeeper的知识还是阅读两份课件，把里面的操作都做一遍，理论都理解一遍，总结一遍。

ZooKeeper基础知识：https://blog.youkuaiyun.com/qq_1018944104/article/details/84797517

ZooKeeper原理和应用：https://blog.youkuaiyun.com/qq_1018944104/article/details/84798722

ZooKeeper的产生背景，设计思路，算法实现相关理论知识介绍

从集中式到分布式必然导致的问题：数据的分布式一致性

分布式一致性解决方案分析：分布式事务、NRW、paxos算法

paxos算法的实现过程

CPA理论

BASE理论 

关于ZooKeeper

1. 概念：分布式的集群管家    分布式服务的协调组件
2. 产生：yahoo 根据lamport发表的论文，是谷歌的chubby的开源实现
3. 作用：组服务、配置管理、节点动态上下线、分布式队列、分布式同步锁...分布式环境中的关于数据一致性保证的各种问题

核心功能：以上所说的各种ZooKeeper的作用都是基于以下两种基础功能实现的

1. znode系统
   1. znode节点：存储数据 和 挂载子节点
   2. 分类：临时/持久    带序列编号/不带序列编号
   3. 临时节点：不能有子节点，谁创建它，就跟着谁同生死
   4. 寻路：znode系统中的任何一个节点都必须是绝对路径，以 / 开头
   5. znode节点存储数据的大小：不能超过1M，最好小于1K
2. 监听机制
   1. 回调
   2. 异步

ZooKeeper集群的特点

1. 数据的最终一致性：一个ZooKeeper集群中所有节点都存储了这个集群中的所有数据。所有节点保存的都是相同的状态。
2. 顺序性
   1. zxid 分布式事务id，投票的时候用
   2. 顺序性保证
      1. 全局有序
      2. 偏序

ZooKeeper集群规划
1、zookeeper是对等架构，但是也有主次之分，主次不是集群安装者分配的，而是zookeeper集群内部选举出来的，zookeeper集群中的所有节点的角色都具有选举权和被选举权利。
zookeeper 主角色是leader 从角色是follower
关于leader是如何得来的？在没有选举出来leader之前，所有的节点的状态都是： looking。在looking期间，所有的节点只会做一件事：选举leader， paxos算法一定要保证在有限的时间内选举出leader，可能说，不能一次选举出来leader，但是没关系，因为在没有选举出来leader之前，这个集群只会一直不停的在进行投票选leader。
2、zookeeper集群的节点个数最好是奇数个
原则：少数服从多数。只有当集群中的超过半数的节点同意某个节点node1当选为leader的话，这个节点node1才会成为leader
准备三台服务器：
hadoop01    hadoop02    hadoop03 分别对应 myid    1       2       3
myid不可缺少，非常重要，也是作为选举leader的一个因素之一，编号必须是1-255之间的一个 不重复的整数，可以不连续，但是不能重复。
问题：那么如果zookeeper集群的节点个数超过255个，怎么办？
为什么zookeeper集群的节点个数不能很多呢？
关于数据同步的问题：如果节点个数越多，同步的难度越大，达到分布式一致性要求的可能性越低
到底是怎样的水平呢？依据其他集群的节点数：
50个节点以内：3个节点  5个节点
100节点：5个节点  7个节点
10000个节点：最终有基本不会超过21个

版本的选择
1、选取不新不旧的稳定版本  zookeeper-3.4.13.tar.gz            
2、根据依赖关系来选择
zookeeper依赖其他组件：只依赖jdk
其他组件依赖于zookeeper：hadoop,sprak,stor,kafka,hbase,......

依赖环境的准备：zookeeper依赖的外部组件只有一个，即jdk， jdk-1.6+以上即可

集群的搭建：核心套路如下
1、从官网下载对应的安装包 或者 源码包(自行编译)，上传到对应的服务器
2、规划安装目录，解压缩zookeeper-3.4.13.tar.gz到安装目录 
      解压缩命令：tar -zxvf zookeeper-3.4.13.tar.gz -C apps/
3、修改配置文件，所有节点同步分发，配置环境变量
      cd zookeeper-3.4.13/conf
      mv zoo_sample.cfg zoo.cfg
      datadir = /home/hadoop/data/zkdata/
      server.1 = hadoop01:2888:3888
      ...
      datalogdir = 配置日志目录，如果没有配置日志目录，默认的日志目录就在：
      zkServer.sh start命令启动的目录！！这个命令在哪个文件夹启动，那么zookeeper.out这个日志文件就在那里
      和hive的自带元数据库的使用很像，使用自带的derby去作为元数据库使用hive的话
      那么数据仓库目录metastore_db和derby.log就在当前这个目录
      scp -r zookeeper-3.4.13/ hadoop03:$PWD
      关于zookeeper：myid的问题
4、初始化
      启动
      zkServer.sh start   开启某个节点上的QPM进程，三个节点分别执行该命令进行启动
      zkServer.sh stop    关闭
      zkServer.sh status  查看角色的状态
      验证是否成功：jps
      基本使用

安装问题总结：
1、最容易出错的问题：是myid 目录要对、内容要对
2、关于环境变量配置
      root：   配置环境变量的文件：/etc/profile，全局配置文件，所有用户可使用  
      hadoop：~/.bash_profile 和 ~/.bashrc，局部环境变量文件，只对当前用户有效

关于功能的初步验证：
1、leader的选举验证：
hadoop02,hadoop03,hadoop04以此启动，则hadoop03是leader
当hadoop03启动好，hadoop04还没有启动的时候。leader就能被选举：
                1、启动的节点的个数，已经超过规定的一半了。这就有可能选举出leader
                2、当新集群启动的时候由于没有任何的数据，所以只能根据myid大小来抉择谁是leader
                标准：谁大谁胜出
2、杀掉hadoop03这个leader之后，hadoop04成为leader
3、当重新启动hadoop03之后，leader角色的节点不变，新启动的hadoop03就是follower
4、当杀掉hadoop04这个leader之后，hadoop03成为新的leader 
5、当改变节点的进程启动顺序之后：hadoop04,hadoop02,hadoop03，谁是leader？是hadoop04
6、如果zk集群是一个全新的集群：hadoop04,hadoop02,hadoop03
启动hadoop02, hadoop04，则leader：hadoop04
先杀掉hadoop04，则leader没有了， 现在只有hadoop02一个节点
再启动hadoop03，这时谁是leader:？是hadoop02
 
选举算法有三个标准：1）数据版本 2）serverid 3）逻辑时钟。比较和判断规则：先判断1，再判断2，再判断3
两种算法：
1、关于新集群的leader的选举
      所有的节点都没有数据，所以最终就一个标准：谁的myid大谁就能胜出
2、关于使用了一段时间的zk集群的leader的选举
      首先是根据数据的版本来确定。如果某个节点的数据版本落后了，那么他一定没有可能成为leader
      能成为leader的节点只有拥有最新版本数据的zk节点。
 
      逻辑时钟：去除掉旧的非法的投票结果。统一逻辑时钟  zxid
 
      myid - serverid
                    如果每次选举过程中，每个节点都优先投票给自己的话，那么永远都选不出来
                    如果第n次选举没有选举出来leader，那么在第n+1次选举中，有部分投票给自己的节点就会妥协，投票给别人
                    myid小的节点投票给myid大的节点 
最终总结：简单来说，如果所有的节点都是同时启动，那么基本上leader应该就是数据版本 和 myid最大的那个节点。但是如果按照某种特定的顺序启动时，刚好启动了超过半数节点，并且这个节点的获取赞成票数超过半数，那么这个节点就是leader。
详细的过程：（5个节点）
1、全新集群
                1、node1(1)启动  looking   follower
                2、node2(2)启动  looking   follower
                3、node3(3)启动            leader
                4、node4(4)启动            follower
                5、node5(5)启动            follower
 
                1、node1(1)启动  looking   follower
                2、node4(4)启动  looking   leader
                3、node3(3)启动            follower
                4、node2(2)启动            follower
                5、node5(5)启动            follower 
2、非全新集群
                1、node1(1, 最新)启动    looking     follower
                2、node4(4, 非最新)启动   looking     follower
                3、node3(3, 最新)启动            leader
                4、node2(2, 非最新)启动           follower
                5、node5(5, 最新)启动            follower
                仅仅只是多了一个判断标准而已：数据版本
 
这种选举算法能不能一定选举出来leader呢？能！因为不管是全新的， 还是不是全新的，都最终需要经过myid的判断，其他的myid小的节点会妥协投票给myid大的节点。掌握了这个规律之后，如何分配集群的性能？
节点的名称：  node1   node2   node3   node4
性能指数：   100 98  56  78
myid :          4   3   1   2
最终的标准是： 性能越好的机器越应该成为leader
 
 
补充一个知识：
1、leader：负责所有的写，负责一部分读
2、follower：只负责读，转发写请求给leader
3、learner B：
                包括follower和observer
                observer:   learner A
proposal    提议的发起者
acceptor    接受者（赞成或者反对）
learner ：A  学习者（没有投票权和被投票权的）

初步使用
 1、Shell
 启动：zkCli.sh    就是连接自己的QPM进程
 如果在hadoop05上执行，不能连接成功，因为连接当前节点，当前节点必须启动QPM进程
 如果在hadoop04中执行，因为hadoop04上的QPM启动正常的。
zkCli.sh -server hadoop02
zkCli.sh -server hadoop02:2181
create
get
set
ls
delete
关于zookeeper集群：因为每个节点都是单独启动的，所以为了能一次性启动所有节点，最好自己编写一个启动和关闭集群的脚本。思路：start-dfs.sh  启动namenode 和 所有的 datanode
start-zk.sh
stop-zk.sh
status-zk.sh
 
帮助大家理解什么是zxid：0x40000abb4880004    0x40000abb4880004
zxid是由两部分组成的：
1、leader
2、自增长的序列号
如果在这个leader在位期间，所创建的所有的session的前半部分都一样
如果换了一个leader之后，那么前面这个值，就会改变
3.4.13这个版本的zxid的生成有改变
 
工具：
1、zooinspector
2、zookeeper eclipse plugin
把6个jar包放置在eclipse安装目录中的plugins目录中
$ECLIPLSE_HOME/plugins
$JAVA_HOME/bin
 
2、API
 maven：项目构建工具
svn/git：代码版本管理工具
 

HA的实现要注意以下几点：
1、standby的状态和active的状态节点必须一致
2、要能做到实时切换而且是自动的
要能做到实时自动切换，如果保证能实现呢？如果保证数据一致呢？使用zookeeper去给你保证
如果真正的active宕机了之后，其实难点不在于启动一个新的主节点，而是要然刚启动的这个新的主节点的数据状态必须要跟原来的active的主节点状态一致。但是，宕机的原来的active主节点的到底是如何宕机的？ 不能确定的
1、namenode进程宕机
2、整个服务器宕机
3、如果服务器被烧毁了呢，这一台服务器就跟 马航航班 一样
 
10G的一个数据文件 最终被切块 成了 80个块
1G = 1024M = 128 * 8  = 8个块
10G  = 80个块
全部带了副本的分散的存储了所有的节点中
blk_001
blk_002
blk_003
blk_004
....
blk_080
blk_081
blk_082
....
只有namenode知道！！！
zookeeper的作用就是保证数据的安全和一致性！！！！
如果一个HDFS集群存储了2000T的数据，最终元数据的大小可能是100G
zookeeper的优势是存储少量的非常关键的数据。而不是大量的一般般重要的数据
解决方案：hadoop做了一个努力，模仿zookeeper的znode实现了一个专门用来存储HDFS的元数据的一个叫做jounal的日志系统
特点：
        1、这个journal系统和zookeeper的工作机制完全一样
        2、这个journal系统的数据不是存储在zookeper中。所以就没有给zk增加额外的管理负担
        3、journal系统也得搭建一个包含多个奇数节点的进程来组成一个集群，这个集群只做一件事：存储HDFS的元数据

hadoop集群的HA集群搭建：
1、准备好了4台服务器，准备好了zookeeper集群
2、从官网中下载源码包进行编译/直接下载安装包
3、上传到服务器
4、规划安装目录
5、解压缩，安装
    tar -zxvf hadoop-2.7.6-centos-6.7.tar.gz -C ~/apps/
6、修改配置文件
        hadoop-env.sh
        core-site.xml
        hdfs-site.xml
        yarn-site.xml
        mapred-site.xml
        slaves
7、安装包同步分发
8、配置环境变量
9、启动zookeeper集群，保证正常运行
10、在规划的三个journal上，分别使用命令启动JournalNode进程
        hadoop-daemon.sh start journalnode
11、在启动的第一个namenode上初始化HDFS
        hdfs namenode -format
12、把11步中初始化HDFS所生成的元数据文件夹拷贝到第二个namenode上去。
13、初始化zkfc，随便找一个namenode节点
        hdfs zkfc -formatZK
14、启动HDFS
        start-dfs.sh
15、启动YARN
16、检验是否成功
        jps
        web ui
        基本使用
        关于pi程序：
        cd $HADOOP_HOME/share/hadoop/mapreduce
        hadoop jar hadoop-mapreduce-examples-2.7.6.jar pi 4 4
        hadoop jar hadoop-mapreduce-examples-2.7.6.jar wordcount /wc/input /wc/output
    17、完整的HA测试

重要的异常： 
log4j:WARN No appenders could be found for logger (org.apache.hadoop.metrics2.lib.MutableMetricsFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Exception in thread "main" java.lang.IllegalArgumentException: java.net.UnknownHostException: myha01
    at org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
    at org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:320)
    at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
    at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:687)
    at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:628)
    at org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
    at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2667)
    at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:93)
    at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2701)
    at org.apache.hadoop.fs.FileSystem$Cache.getUnique(FileSystem.java:2689)
    at org.apache.hadoop.fs.FileSystem.newInstance(FileSystem.java:419)
    at org.apache.hadoop.fs.FileSystem.newInstance(FileSystem.java:427)
    at com.aura.hdfs1808.first.HDFS1808.main(HDFS1808.java:18)
Caused by: java.net.UnknownHostException: myha01
    ... 13 more
解决方案：哪些地方配置了这个myha01, 这个东西，HDFS客户端程序不认识
Permission denied: user=Administrator, access=WRITE, inode="/test":hadoop:supergroup:drwxr-xr-x
System.setProperty("HADOOP_USER_NAME", "hadoop");
普通的hadoop集群：SPOF
高可用的集群和普通的集群的共同的未解决的问题：主从架构中，不仅有SPOF，还有单节点的压力过载问题
主从架构  如果主节点宕机了的话，整个集群一定不可用么？
hbase：
        主从架构
        master  regionserver
主节点的压力问题
        HDFS： 所有增删改查 全部要经过namenode
        HBase:  所有增删改查都不会经过master
联邦机制
一个anmenode节点 管理了 10000个节点， 使用两个namenode，一个namenode管理其中的5000个，另外一个namenode管理另外的5000个，每个namenode只是管理其中的一部分数据。不管理另外一部分数据。
hdfS中的所有的数据。按照某种规则进行分区
nameonde1管理1号分区
namenode2管理2号分区
3.x当中才有具体的完整实现
腾讯的Spark集群：10000节点
联通：7000

补充知识：

1、关于版本：name-x.y.z.tar.gz ，x.y是大版本： 新特性，大功能的bug解决 。z是小版本： bug fix 
hadoop-2.2
hadoop-2.3
...
 hadoop-2.7.x
hadoop-2.8
hadoop-2.9
hadoop-3.x
       hadoop-3.0.x
       hadoop-3.1.x
工作集群的hadoop版本：
       hadoop-2.2.x   高可用
       hadoop-2.4.x   高可用