分布式注册中心原理分布式服务注册中心

转载

mob64ca140530fb 2024-05-13 16:59:10

文章标签 分布式注册中心原理 zookeeper 数据服务器 文章分类 运维

理解注册中心：服务管理,核心是有个服务注册表，心跳机制动态维护
服务提供者provider: 启动的时候向注册中心上报自己的网络信息
服务消费者consumer: 启动的时候向注册中心上报自己的网络信息，拉取provider的相关网络信息

为什么要用
微服务应用和机器越来越多，调用方需要知道接口的网络地址，如果靠配置文件的方式去控制网络地址，对于
动态新增机器，维护带来很大问题
主流的注册中心
zookeeper、Eureka、consul、etcd 等
分布式应用知识CAP理论知识
CAP定理
指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容
错性），三者不可同时获得。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完
全一致，越多节点，数据同步越耗时）
强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。单调一致性
（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到
比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。
会话一致性（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在
本次会话中就不会再读到比这值更旧的值会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用
户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。
最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致
的状态，只是所需时间不能保障。
弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。
可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时
间）
分区容错性（P）：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几
个，不影响服务，越多机器越好）
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包
等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

win、linux双环境安装zookeeper

下载zookeeper https://zookeeper.apache.org/
配置jdk 参考以下博客配置
解压下载好的zk
重命名conf目录下的zoo_sample.cfg 文件为zoo.cfg 并修改里面的内容
直接运行bin目录下的zkServer，单一实例便安装好
主要配置项
tickTime 心跳基本时间单位，毫秒级，ZK基本上所有的时间都是这个时间的整数倍。
initLimit 集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数
syncLimit 集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数
dataDir 内存数据库快照存放地址，如果没有指定事务日志存放地址(dataLogDir)，默认也是存放在这个路径
下，建议两个地址分开存放到不同的设备上。
centos下安装zk
tar -zxvf zookeeper-3.4.12.tar.gz -C /usr/local/
cd /usr/local/zookeeper-3.4.12/conf
mv zoo_sample.cfg zoo.cfg
vim zoo.cfg
修改dataDir /usr/local/zookeeper-3.4.12/data
将整个文件夹所属权赋予zookeeper用户 chown -R zookeeper:zookeeper /usr/local/zookeeper-3.4.12
切换到zookeeper用户 su zookeeper
cd /usr/local/zookeeper-3.4.12/bin 找到对应的zkServer.sh启动

ZooKeeper数据模型

zookeeper的数据模型类似于linux下的文件目录
/usr/local /usr/local/tomcat
每一个节点都叫做zNode，可以有子节点，也可以有数据
每个节点都能设置相应的权限控制用户的访问
每个节点存储的数据不宜过大
每个节点都带有一个版本号，数据变更时，版本号变更（乐观锁）
节点分永久节点跟临时节点

zookeeper常用命令之zkCli

zkCli.sh
不填后面的参数，默认连接的就是localhost:2181
win下面运行的是.cmd结尾的文件，linux下运行的是.sh结尾的文件
连接远程服务器
zkCli.sh -timeout 0 -r -server ip:port
创建节点 create [-s] [-e] path data acl -s表示创建顺序节点 -e表示创建临时节点 data表示创建的节点的数据内
容
查看
获取节点的子节点 ls path
获取节点的数据 get path
查看节点状态 stat path
cZxid = 0x3 --事务id
ctime = Tue Dec 04 10:37:58 EST 2018 --节点创建的时候的时间
mZxid = 0x3 --最后一次更新时的事务id
mtime = Tue Dec 04 10:37:58 EST 2018 最后一次更新的时间
pZxid = 0x3 该节点的子节-点列表最后一次被修改的事务id
cversion = 0 子节点列表的版本
dataVersion = 0 数据内容的版本
aclVersion= 0 acl版本
ephemeralOwner = 0x0 用于临时节点，表示创建该临时节点的事务id，如果当前的节点不是临时节点，该字段值为0
dataLength = 8 数据内容的长度
numChildren = 0 子节点的数量
获取节点的子节点以及当前节点的状态 ls2 path
修改节点的数据 set path data [version]
删除节点数据
delete path [version] 删除节点，如果此时该节点有子节点，则不允许删除
rmr path 递归删除整个节点

zookeeper session机制

用于客户端与服务端之间的连接，可设置超时时间,通过心跳包的机制（客户端向服务端ping包请求）检查心
跳结束，session就过期
session过期的时候，该session创建的所有临时节点都会被抛弃

zookeeper watcher机制

对节点的watcher操作 get stat针对每一个节点的操作，都可以有一个监控者，当节点发生变化，会触发watcher事件 zk中watcher是一次性
的，触发后立即销毁所有有监控者的节点的变更操作都能触发watcher事件
子节点的watcher操作（监控父节点，当父节点对应的子节点发生变更的时候，父节点上的watcher事件会被触
发） ls ls2 增删会触发、修改不会，如果子节点再去新增子节点，不会触发（也就是说，触发watcher事件一
定是直系子节点）

zookeeper的acl（access control lists）权限控制

针对节点可以设置相关的读写等权限，目的是为了保证数据的安全性
权限permissions可以指定不同的权限范围及角色
常用的命令
getAcl 获取节点权限 setAcl 设置节点权限 addauth 输入认证授权信息，注册时输入明文密码，但是在zk里，
以加密的形式保存
acl的组成 [scheme🆔permissions]
scheme 授权机制
world下只有一个id，也就是anyone，表示所有人 world:anyone:permissions
auth 代表认证登录，需要注册用户有权限才可以 auth:user:password:permissions
digest 需要密码加密才能访问 digest:username:BASE64(SHA1(password)):permissions(跟auth区别在于，
auth明文，digest为密文)
ip ip:localhost:psermissions
super 代表超管，拥有所有的权限；
打开zk目录下的/bin/zkServer.sh服务器脚本文件，找到如下一行：
nohup $JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-
Dzookeeper.root.logger=${ZOO_LOG4J_PROP}"
加上 "-Dzookeeper.DigestAuthenticationProvider.superDigest=super:xQJmxLMiHGwaqBvst5y6rkB6HQs="
id：允许访问的用户
permissions：权限组合字符串
cdrwa
c create 创建子节点
d delete 删除子节点
r read 读取节点的数据
w write 写入数据
a admin 可管理的权限
cdrwa cdr cdw
acl的使用场景
开发环境跟测试环境，使用acl就可以进行分离，开发者无权去操作测试的节点
生产环境上控制指定ip的服务可以访问相关的节点
zookeeper选举机制
zk集群核心知识之三种角色及其作用
leader：作为整个zk集群写请求的唯一处理者，并负责进行投票的发起和决议，更新系统的状态。
follower：接收客户端请求，处理读请求，并向客户端返回结果；将写请求转给 Leader；在选举 Leader过程
中参与投票。
observer：可以理解为无选举投票权的 Flollower，其主要是为了协助 Follower 处理更多的读请求。如果
Zookeeper 集群的读请求负载很高，或者客户端非常非常多，多到跨机房，则可以设置一些 Observer 服务
器，以提高读取的吞吐量。

zk核心知识之注册中心常见的三种模式

k的核心是广播机制，该机制保证了各个zk之间数据同步（数据一致性）。zk实现的机制为ZAB协议
恢复模式：如果leader崩溃，这个时候就会进入恢复模式，使整个zk集群恢复到正常的工作状态
同步模式：新的leader选举出来后，就乎进入同步模式（各个follower会去同步新的leader上的数据），当大多
数zkServer完成了与leader的状态同步之后，恢复模式就结束
广播模式：客户端想写入数据，这个时候leader发起提议，当leader的提议被大多数的zkServer统一之后，
leader就会去修改自身的数据，并将修改后的数据广播给其他的follower

zk集群选举核心概念及选举时状态

myid
这是 zk 集群中服务器的唯一标识，称为 myid。例如，有三个 zk 服务器，那么编号分别是 1,2,3。
zxid
ReentranReadWriteLock 32位
高位低位
0000000000000000 0000000000000000
epoch xid
00000000000000000000000000000000 00000000000000000000000000000000
zxid 为 Long 类型，其中高 32 位表示 epoch，低 32 位表示 xid。即 zxid 由两部分构成：epoch 与xid。
每个 Leader 都会具有一个不同的 epoch 值，表示一个时期、时代。新的 Leader 产生，则会更新所有
zkServer 的 zxid 中的 epoch。而 xid 则为 zk 的事务 id，每一个写操作都是一个事务，都会有一个
xid。每一个写操作都需要由 Leader 发起一个提议，由所有 Follower 表决是否同意本次写操作。
*逻辑时钟
逻辑时钟，Logicalclock，是一个整型数，该概念在选举时称为 logicalclock，而在 zxid 中则为 epoch 的值。
即 epoch 与 logicalclock 是同一个值，在不同情况下的不同名称。
zk的选举状态
LOOKING，选举状态(查找 Leader 的状态)。
LEADING，领导者状态。处于该状态的服务器称为 Leader。
FOLLOWING，随从状态，同步 leader 状态。处于该状态的服务器称为 Follower
OBSERVING，观察状态，同步 leader 状态。处于该状态的服务器称为 Observer。

zk集群选举发生的时机及选举算法

发生时机：整个集群群龙无首的时候（1.服务启动 2.leader宕机之后）
选举机制：集群中，半数zkServer同意，则产生新的leader（搭建集群时，一般都是奇数个）
三台服务器，最多允许一台宕机，四台服务器，也是最多允许一台宕机
选举算法：
对比（myid，zxid），先对比zxid，zxid大者（大表示数据越新）胜出，成为leader，如果zxid一致，则myid
大者成为leader

*** 实战--zk集群搭建**

端口的作用 2181 对client端提供服务 2888 集群内及其通讯使用的端口 3888 集群选举leader
修改zk配置

编辑zk的conf目录下的zoo.cfg dataDir=/usr/local/zookeeper-3.4.12/data server.1=xdclass1:2888:3888
server.2=xdclass2:2888:3888 server.3=xdclass3:2888:3888
2.在zk的根目录下，新建一个data目录，并在data目录下新增一个myid的文件
3.将修改好配置的zk，分别放到三台服务器的/usr/local/,并将目录权限改为zookeeper用户
4.三台服务器，分别新增一个叫做zookeeper的用户 useradd zookeeper
5.三台服务器，均修改/usr/local/zookeeper-3.4.12/data/目录里的myid文件,文件内容是一个数字，对应server.1=xdclass1 里的1
6.三台服务器的zk的权限，都赋给zookeeper用户
7.关闭防火墙