关于分布式:zookeeper笔记

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 data
    set /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. 批改数据 
  @Test
  public 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. 敞开连贯
  @After
  public void after(){client.close();
  }
  

选举机制

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

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

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

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

、