分布式存储-ShardingSphere 分布式治理 (based on zookeeper)

分布式存储-ShardingSphere 分布式治理 (based on zookeeper)

  其实前面几篇,关于shardingSphere的我知道的功能点已经聊得差不多了,但是现在多节点集群部署的方式已经成为了一种趋势,而如果每个节点中的配置文件都需要手动一个个修改的话,那将为运维工作带来了很大的不愉快,所有ShardingShere内部整合了Zk,实现了配置文件的动态配置。本篇主要聊聊:

  • ShardingSphere整合zookeeper的配置动态更新。
  • zookeeper的大体介绍

ShardingSphere和Zk实现(一处修改配置文件,多处通过感知)

首先导入pom

        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>shardingsphere-governance-repository-zookeeper-curator</artifactId>
            <version>5.0.0-alpha</version>
        </dependency>
        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>shardingsphere-jdbc-governance-spring-boot-starter</artifactId>
            <version>5.0.0-alpha</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.shardingsphere</groupId>
                    <artifactId>shardingsphere-test</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
View Code

然后在application文件中加上zk的路径和配置

spring.shardingsphere.governance.registry-center.type=ZooKeeper
spring.shardingsphere.governance.registry-center.server-lists=192.168.43.3:2181
spring.shardingsphere.governance.registry-center.props.maxRetries=4
spring.shardingsphere.governance.registry-center.props.retryIntervalMilliseconds=6000
View Code

这个时候application中还有咱们对shardingSphere的配置,因为在初始化的时候,shardingSphere会把和它相关的配置变成yml传递到zk上,我们以后只要修改zk上面rule下面的配置就可以被shardingShpere感知了!

 当我们修改zk上的信息的时候,我们本地就动态感知了。

 问题来了,sharingSphere为啥就要用zk呢,zk为啥这么受欢迎?下面我们就开始聊聊zk!

outline of Apache Zookeeper

zookeeper是一个分布式协调中间件,目的就是在分布式情况下,大家都基于某个点达成一致。为啥要引入他呢,因为在分布式的情况下由于网络通信的原因,在某些场景下必须在多个节点下做出一个决定,比如,和数据一致性。有一个有名的例子就是拜占庭将军的故事。拜占庭将军分布在不同的拜占庭王国中,当他们要决定是否要打仗的时候,就发出票据去投票决定,但是在发送票据的途中可能有叛徒,最终让战争失败。那针对这些问题就要有一个规则。这个规则就是paxos算法(一个非常早期的数据一致性算法),而zk就是基于paxos算法上的一个中间件。总而言之:那就所有节点去找zk,然后zk帮忙决定谁是leader.

chubby的分布式协调:

zk的前身是chubby,因为chubby不开源,所以zk就被创造出来了。chubby当时是这样做的:所有的节点去chubby上创建一个文件,前提是,文件名是唯一的,那也就证明,多个节点创建只有一个节点是成功的。那这个创建成功的节点就是learder。

zk的分布式协调:

zk也是,类似chubby的文件,但是他不是文件,他是树形节点,也就是说他的数据是以树的形式去存储的。然后每个节点都是key和value的形式存储数据的。就像上面的shardingSphere的配置文件一样。rule是key,value存储的就是yml格式的配置。 就像这样。

他和chubby一样,他的节点在同一节点下也是唯一的,比如我们创建一个glen的key,就不能再次创建相同的key了。那以这种方式,谁先创建谁就是learder了,

 zk使用:我这里使用的是zk 3.6.3版本,这是一个稳定版本。安装这里不赘述了,使用下面地址,直接在linux上解压就行,初次使用zookeeper,需要将conf目录下的zoo_sample.cfg文件copy一份重命名为zoo.cfg,并且修改dataDir目录,dataDir表示日志文件存放的路径 

【下载地址】:https://mirrors.bfsu.edu.cn/apache/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz 
【常用命令】:
  • 启动ZK服务:
    •   bin/zkServer.sh start
  • 查看ZK服务状态:
    •   bin/zkServer.sh status
  • 停止ZK服务:
    •   bin/zkServer.sh stop
  •  重启ZK服务:
    •   bin/zkServer.sh restart
  • 连接服务器
    • zkCli.sh -timeout 0 -r -server ip:port  

【Zookeeper的数据结构】 :

zookeeper的视图结构和标准的文件系统非常类似,每一个节点称之为ZNode, 是zookeeper的最小单元。每个znode上都可以保存数据以及挂载子节点,构成一个层次化的树形结构 。
比如说要创建一个名称为Glen,年龄为18的person,他展示的就是这样的一个树形。

我们在创建的时候就要一步一步创建。

 

【 ZK节点的特性】

持久化节点】: 数据会一直存储在磁盘,默认情况下创建的都是持久化节点

【临时节点】:这是和会话周期绑定的,当会话结束,临时节点就会被删除。

【他们的不同】:持久化节点没有临时id,而临时节点有临时id【ephemeralOwner】,zk就可以通过这个临时id去删除对应的节点。

 

 其他的节点:

【有序节点(分为临时和持久化有序节点)】:他会按照顺序进行排列,我们创建了一个seq节点,在他下面创建这些有序节点。

 

 【容器节点】:当容器节点下面的最后一个子节点被删除后,他就会被标记,并且在一定时间内删除。

 【ttl节点】:如果某个节点设置为TTL节点类型,那么这个节点在指定TTL时间(单位为毫秒)段内没有修改并且没有子节点时,该节点会在一段时间后被删除。(默认情况下没有被开启,需要被手动开启)必须在zookeeper的bin/zkService.sh中的启动zookeeper的java环境中设置环境变量zookeeper.extendedTypesEnabled=true。

【节点特性】:

  • 同级节点不能有相同的名称的节点
  • 临时节点不能有子节点(因为如果临时节点中有一个持久化节点被创建就不合理,是为了规避这种现象)

我们可以用上面的这些特性去实现相关的功能,比如分布式锁:比如有三个客户端抢占锁,那我这三个客户端就都去zk上创建一个临时有序节点,谁的序号最小,谁就可以获得这个分布式锁。

 

posted @ 2021-11-16 12:02  UpGx  阅读(677)  评论(0编辑  收藏  举报