共计 2667 个字符,预计需要花费 7 分钟才能阅读完成。
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 大的,过半产生老大
、
正文完