zookeeper

1.YARN主要包括：ResourceManager,NodeManager,ApplicationMaster,Container;
  MapReduce作业提交之后，在nodeManager节点首先会new 一个ApplicationMaster，然后ApplicationMaster向ResourceManager申请资源，ResourceManager将ApplicationMaster申请到的资源交给nodemanager,
  nodemanager会将资源封装为一个container,container是进程级别的，一个Map task 或者一个Reduce task运行完成之后，container就会消失！
 
 
2.zookeeper可以做高可用，但是这是它的副产品！
   
   
3.面试谈的时候很重要，绝对不是干的多久薪资高，干的少也有可能薪资高！


4.zookeeper是为了保证分布式的数据一致性的！


5.Zookeeper 是 Google 的 Chubby一个开源的实现,是 Hadoop 的分布式协调服务
    它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等

6.zookeeper集群节点最好是奇数的，当然偶数个数也没问题！



7.为什么使用Zookeeper？
    ? 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）
    ? 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制
    ? 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器
    ? ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用
    
    
8.Keepalive高可用的缺点：    
    ? Keepalived监控节点不好管理
    ? Keepalive 采用优先级监控
        ? 没有协同工作
        ? 功能单一
    ? Keepalive可扩展性差
    
    注：keepalived 主挂了之后再重启之后，leader领导权会抢回来！
    

8.Zookeeper优点
    特点                                         说明
    最终一致性                       为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能
    可靠性                            如果消息被到一台服务器接受，那么它将被所有的服务器接受。
    实时性                            Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。（leader上一定会有最新的数据）
    独立性                            各个Client之间互不干预
    原子性                            更新只能成功或者失败，没有中间状态。
    顺序性                            所有Server，同一消息发布顺序一致。（leader里面有一个队列，这也保证了按着接收到请求的顺序性）
    
    
    注：（中间某一时刻可能信息不同，所以是最终一致性） ，leader上一定会有最新的数据，leader里面有一个队列，这也保证了按着接收到请求的顺序性！
    

    
9.zookeeper的工作原理，
    1.每个Server在内存中存储了一份数据；（这里是在内存中存储了数据哦，当然也会定期落到磁盘中）
    2.Zookeeper启动时，将从实例中选举一个leader（Paxos协议）
    3.Leader负责处理数据更新等操作
    4.一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。
    
10.Zookeeper能帮我们做什么？
    ? Hadoop,使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等.
    ? HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等.

11.Zookeeper的安装和配置（集群模式）
    ? 创建myid文件，server1机器的内容为：1，server2机器的内容为：2，server3机器的内容为：3
    ? 在conf目录下创建一个配置文件zoo.cfg，
        tickTime=2000
        dataDir=/Users/zdandljb/zookeeper/data
        dataLogDir=/Users/zdandljb/zookeeper/dataLog
        clientPort=2181
        initLimit=5
        syncLimit=2
        server.1=server1:2888:3888
        server.2=server2:2888:3888
        server.3=server3:2888:3888
        
        
12. ? tickTime：发送心跳的间隔时间，单位：毫秒
    ? dataDir：zookeeper保存数据的目录。（zookeeper启动时的数据是放在内存中的，但是等到一定时间之后也会将数据保存到本地目录中）
    ? clientPort：客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求（默认是2181）。
    ? initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
    ? syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息（是否还活着以及信息同步），请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
    ? server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

    
13.client复制增删改查请求，
   follower:具有投票功能
   leader： leader向follower提议,leader收到follower的投票回复，然后决定到底提议是否通过 ；然后同步信息，leader本身也具有投票权！
   

14.keepalived 主挂了之后再重启之后，leader领导权会抢回来！



15.因为在zoo.cfg配置信息中配置了集群的信息，所以它知道它的zookeeper集群是哪几台，所以启动了一台的服务之后，实际上还是没法运行的，此时没有leader,也没有follower！


16.用jps查看进程的时候，QuorunPeerMain有这个服务，不代表集群已经启动了,因为这时候还没有leader和follower状态,当leader挂了的时候，follower谁先发现，一般这家伙就会选自己为leader,然后就会征求其它follower的同意！


17.来的早不如来的巧，时机要比时间更重要，Timing more important than time！


18.Zookeeper的角色
    ? 领导者（leader），负责进行投票的发起和决议，更新系统状态
    ? 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
    ? Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
    ? 客户端（client），请求发起方

    
    注意：observer:是不能投票的，将写请求转发给leader，并同步leader的状态，leader和follower都是可以投票的，票数必须超过一般才能选举出来，一般对于公司是用不到observer的！
         follower一般也不会太多，太多的话选举和每一次更新都会去找到所有的follower机器！也就是zookeeper集群也不会太大！
    
19.Zookeeper的读写机制
    ? Zookeeper是一个由多个server组成的集群
    ? 一个leader，多个follower
    ? 每个server保存一份数据副本
    ? 全局数据一致
    ? 分布式读写
    ? 更新请求转发，由leader实施



20.Zookeeper的保证
    ? 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
    ? 数据更新原子性，一次数据更新要么成功，要么失败
    ? 全局唯一数据视图， client无论连接到哪个server，数据视图都是一致的
    ? 实时性，在一定事件范围内， client能读到最新数据

    
21.为什么zookeeper要搭建偶数台？
   1.容错，（奇数台效果可以等同于偶数台，而且选举更节省时间）
   2.如果挂掉一般那么就选举不出leader了，防止脑裂！
   
   
   
22.注意：增删改的时候也需要投票，只要半数以上通过，那么就意味着这次投票成功，可以增删改！




23.zookeeper实际上是选自己，做到了自己是高可用的！



24.keepalived与zookeeper都可以做高可用，那这两者有什么区别呢？
   区别：1：
         nginx 的时候更倾向于keepalived，keepalived会主动的访问nginx来保持通信！  --------------->谁主动谁被动！
         hadoop大数据的高可用是用Zookeeper（HDFS的NameNode和Yarn中的Resourcemanager）！
        
         2.keepalived 自身当请求多了的时候，主keepalive受不了的时候，那就挂了！再去从，从机也会挂！就这么一直挂下去就完了！
           zookeeper 的每一个zkserver都可以响应请求，做到了负载均衡！

         3.我们之所以hadoop之后用到了zookeeper，是因为除了高可用用到了zookeeper,但是同时别忽略了zookeeper中还可以保存了其它的数据信息，例如Hbase的RegionServer的信息等等！
        
        
        
25.投票的时候实际上就是增删改，这些数据就是在内存中完成的！


26.选举leader的时候，防止脑裂(即使脑裂之后也只有一个leader)，数据更新的时候都会用到超过半数,当半数以上的机器更新成功了，我们就commit一下！


27.选举leader和更新数据的时候，会从数据最新的那些机子中选出leader！


28.为什么zookeeper集群的数目，一般为奇数个？
    Leader选举算法采用了Paxos协议；
    Paxos核心思想：当多数Server写成功，则任务数据写成功
    如果有3个Server，则两个写成功即可；
    如果有4或5个Server，则三个写成功即可。
    Server数目一般为奇数（3、 5、 7）
    如果有3个Server，则最多允许1个Server挂掉；
    如果有4个Server，则同样最多允许1个Server挂掉
    由此，我们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。


29.Zookeeper的数据模型
    ? 层次化的目录结构，命名符合常规文件系统规范
    ? 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
    ? 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
    ? Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
    ? 客户端应用可以在节点上设置监视器
    ? 节点不支持部分读写，而是一次性完整读写
    
    
30：在mysql中建立索引实际上就是将索引加载到内存中，从内存中读数据就会快(存储在硬盘中的，MYSQL需要的时侯调入部分内容到内存。)!

31.命令行工具的一些简单操作如下：
    1. 显示根目录下、文件： ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容
    2. 显示根目录下、文件： ls2 / 查看当前节点数据并能看到更新次数等数据
    3. 创建文件，并设置初始内容： create /zk "test" 创建一个新的 znode节点“ zk ”以及与它关联的字符串
    4. 获取文件内容： get /zk 确认 znode 是否包含我们所创建的字符串
    5. 修改文件内容： set /zk "zkbak" 对 zk 所关联的字符串进行设置
    6. 删除文件： delete /zk 将刚才创建的 znode 删除
    7. 退出客户端： quit
    8. 帮助命令： help
    
32.Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等.

33.Zookeeper的数据模型
    ? 层次化的目录结构，命名符合常规文件系统规范
    ? 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
    ? 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
    ? Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
    ? 客户端应用可以在节点上设置监视器
    ? 节点不支持部分读写，而是一次性完整读写


34.Zookeeper的节点
    ? Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
    ? Znode的类型在创建时确定并且之后不能再修改
    ? 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
    ? 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
    ? Znode有四种形式的目录节点
    ? PERSISTENT、
    ? EPHEMERAL
    ? PERSISTENT_SEQUENTIAL、
    ? EPHEMERAL_SEQUENTIAL

    
35. Watcher 在 ZooKeeper 是一个核心功能， Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目
    录节点上的 Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应
    ? 可以设置观察的操作：exists,getChildren,getData
    ? 可以触发观察的操作：create,delete,setData


36.在NameNode的高可用的时候，zkfc会监控namenode的状态，并将状态信息写入到zookeeper内存数据库中的一个节点（znode节点）中，所以Namenode和Resourcemanager的高可用都是利用zookeeper的znode临时节点的一个特性！

37.分布式锁实际上是自己获得的，实际上Active NameNode靠zookeeper的分布式锁来实现的！

38.增删改请求都发给了leader,所以它能够保证顺序性！



39.zookeeper数据保存在内存，会定期落地磁盘 dataDir里面！

40.zookeeper为什么是奇数个？
   1.容错和偶数是一样的，所以没必要多一台
   2.防止脑裂
   
41.为什么要超过半数？


   3,5,7


   
42.CDH通过修改一处，在所有机器上的配置文件都改了就是通过zookeeper来实现的！


43.zookeeper的主产品是：
     1.做分布式数据一致性，（zookeeper集群本身高可用，里面可以存储hbase，storm的元数据信息！）
     2.其副产品是实现了高可用（就是用分布式锁实现的，保持一致性）！