关于分布式: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 大的，过半产生老大

、

zookeeper

选举机制