zookeeper

  • 作用：分布式协调服务框架，解决分布式集群中利用零碎的一致性问题，实质是一个文件存储系统，与es不同他仅有一套主从，主节点负责事务相干，从节点收到事务的申请转发给主节点，从节点负责读

  • 性质

    • 全局一致性：每个服务器保留一份雷同的数据
    • 可靠性：音讯被一台接管，将被所有接管

    • 程序性

      • 全局有序，在服务端，先插入的肯定在后插入的后面
      • 偏序，客户端将数据插入a到zookeeper，在插入b到zookeeper，客户端在看数据时a在b前
    • 数据更新原子性：数据更新要么全副胜利要么失败
    • 实时性：主节点数据产生扭转后，其余结点会立刻感知数据变动信息，以及实时能感知到服务器一些状态
  • 与一般文件系统类似，外部各节点存在命名空间，是一种树形构造，在zookeeper中各个节点被称为znode

  • 然而zookeeper的节点和一般零碎节点存在区别

    • 节点具备兼具文件和目录两种特点，一般文件系统二者拆散

      create -s /test/child1 acl  # 能够配置子节点就像目录一样,acl为权限create -s /test aaaaa acl   # 也能够输出文件内容,acl为权限
    • 原子性操作
    • 大小又限度znode<1M，理论应用远小于此值
    • 通过绝对路径援用

  • 节点类型，在创立时就曾经决定

    • 永恒节点，只有用户真正执行删除操作才会被删除

      • 非序列化节点

      • 序列化节点。 create -s

        • 建设文件a.txt会在后边追加序列号10位初始为0，

    • 长期会话节点，会话完结长期节点删除，且不容许构建子节点

      • 非序列化节点
      • 序列化节点

  • 操作

    • 创立节点

      create    /zk01    aaaaa # 永恒create -s /zk02 bbbbb # 永恒序列化create -e /zk03 ccccc # 长期create -e -s /zk04 dd # 长期序列化create /zk05/zk06 aaa # 带子节点的须要从父节点开始建

    • ls,get和ls2

      ls path [watch] # 查看根目录下有哪些节点ls2 path [watch] # 查看根目录下的详细信息#ls2 /#dataVersion 数据版本号，每次set+1，即便设置雷同值仍会扭转#cversion 子节点的版本号， znode子节点变动时cversion减少1#cZxid znode创立事务id#mZxid znode批改的事务id#ctime 创立的工夫戳#mtime 更新产生的工夫戳#ephemeralOwner 长期节点有该sessionid,不是长期节点get path [watch] # 指定节点的数据内容和属性信息

    • Set 更新

      set path dataset /zk01 aaa每次批改笼罩原始危机

    • 删除节点

      rmr path #递归删除节点delete path [version]    # 一级一级删，如果有子节点无奈删除

    • zookeeper限度quota

      Setquota -n|-b val path        # n为最多节点数， -b每个节点的数据量长度# -n 别忘了算自身，并且即便n与b都超出了也不过就是日志中warning，工作依然可能进行，在哪个目录下启动，日志就会生成在哪个目录# -b 与 -n只有其中一个能够失效

    • 勾销限度

      delquota [-n|-b] path   # 限度必须先删除后设置
    • 查看历史history

  • 公布订阅者，观察者模式

    • 性质

      • 一次性触发，后续产生雷同事件不再触发

      • 事件封装，WatchedEvent对象来封装服务端事件并传递

        告诉状态（keeperState），事件类型（EventType）和节点门路（path）
      • event异步发送 :watcher告诉事件从服务端发送到客户端是异步的
      • 先注册再发送

    • 步骤流程

      • 1.注册绑定进行监听

      • 2.事件产生触发watcher

        get 节点 watch

    • 该模式可用作

      • zookeeper解决服务器高低线操作

        • 长期节点+watcher监听机制
        • 没有zookeeper就用心跳呗

      • 多节点抉择主节点

        • 抢锁机制：长期节点(在master目录下创立，谁创立胜利谁就是主节点)+watcher(从节点时刻舰艇master是否宕机，宕机就能够再反复这个抢master的步骤)+quota(限度只有一个子节点)

  • java操作zookeeper

    • curator
    // 1.创立zookeeper连贯对象写去before  @Before  public void before(){    ExponentialBackoffRetry retry = new ExponentialBackoffRetry(1000,3);  String connectStr = "node1:2181,node2:2181,node3:2181";  client = CuratorFrameworkFactory.newClient(connectStr, 5000, 5000, retry);  // 启动客户端  client.start();  }// 2.批改数据 @Testpublic void test02() throws Exception{client.setData().forPath("/zk_java01", "我爱你,祖国".getBytes()); // delete.forpath// 或deletechildrenifneeded// 或client.setData().forPath("/zk_java01", "我爱你,祖国".getBytes());// 设置后间接命令行是拿不到utf8的字串的须要在代码中解决为字符串// String operatorObjStr = new String(bytes);// System.out.println(operatorObjStr);}// 3.敞开连贯@Afterpublic void after(){  client.close();}

选举机制

  • 第一种策略全新个体选举：在第一次启动zookeeper集群的时候

    • 整个集群配置为：3个节点
    • 当启动一台时，票投给本人，但集群启动数量没过半，即便投票了集群仍然没有启动状态
    • 当启动第二台时，整个集群中曾经启动过半，因为之前没有选举出老大，会让之前所有节点从新投票，默认状况下投给id最大的，第二台即为leader
    • 启动第三台时，因为曾经有leader，id是2比3小然而无奈再次选举

  • 第二种策略非全新个体选举：往后启动zookeeper集群的时候

    • 当启动一台时，票投给本人，但集群启动数量没过半，即便投票了集群仍然没有启动状态
    • 当启动第二台时，整个集群中曾经启动过半，因为之前没有选举出老大，会让之前所有节点从新投票，此时票会投给数据量多的(个别不宕机数据量都一样，宕机的话数据量多表名信息更靠近事实)，如果都一样还是投给id大的，过半产生老大

、