服务器搭建网站空间,天台网站建设,手机在线画图工具,微信小程序广告投放价格表Zookeeper介绍
什么是Zookeeper
ZooKeeper 是⼀种分布式协调组件#xff0c;用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper 通过其简单的架构和 API 解决了这个问题。ZooKeeper 允许开发人员专注于核心应用程序逻辑#xff0c;而不必担心应用…Zookeeper介绍
什么是Zookeeper
ZooKeeper 是⼀种分布式协调组件用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper 通过其简单的架构和 API 解决了这个问题。ZooKeeper 允许开发人员专注于核心应用程序逻辑而不必担心应用程序的分布式特性。
Zookeeper的应用场景
分布式协调组件 在分布式系统中需要有zookeeper作为分布式协调组件协调分布式系统中的状态。
分布式锁
zk在实现分布式锁上可以做到强⼀致性分布式锁相关的知识在后续的ZAB协议中介绍。
无状态化实现 zookeeper可以保存登录信息保证分布式登录系统多个系统无需重复登录。
搭建Zookeeper服务器
安装启动
zk由Java编写安装依赖Java环境 上传zookeeper压缩包 解压缩
tar -zxvf apache-zookeeper-3.7.1-bin.tar.gz zk目录结构
启动zookeeperconf文件夹中需要zoo.cfg文件 zoo_sample.cfg配置文件说明
# zookeeper时间配置中的基本单位 (毫秒)
tickTime2000
# 允许follower初始化连接到leader最⼤时⻓它表示tickTime时间倍数即:initLimit*tickTime
initLimit10
# 允许follower与leader数据同步最⼤时⻓它表示tickTime时间倍数
syncLimit5
#zookeper 数据存储⽬录及⽇志保存⽬录如果没有指明dataLogDir则⽇志也保存在这个⽂件中
dataDir/tmp/zookeeper
#对客户端提供的端⼝号
clientPort2181
#单个客户端与zookeeper最⼤并发连接数
maxClientCnxns60
# 保存的数据快照数量之外的将会被清除
autopurge.snapRetainCount3
#⾃动触发清除任务时间间隔⼩时为单位。默认为0表示不⾃动清除。
autopurge.purgeInterval1稍作修改然后重命名为zoo.cfg
mv zoo_sample.cfg zoo.cfgZookeeper服务器的操作命令
启动zk服务器指定配置文件
./zkServer.sh start ../conf/zoo.cfg 重启zk服务器
./zkServer.sh restart ../conf/zoo.cfg 查看zk服务器状态
./zkServer.sh status ../conf/zoo.cfg停止zk服务器
./zkServer.sh stop ../conf/zoo.cfgZookeeper内部的数据模型
zk是如何保存数据的
zk中的数据是保存在节点上的节点就是znode多个znode之间构成⼀颗树的⽬录结构类似Linux目录结构。 顶层目录为/
树是由节点所组成Zookeeper的数据存储也同样是基于节点这种节点叫做 Znode
不同于树的节点Znode 的引用方式是路径引用类似于⽂件路径
/service/org-service这样的层级结构让每⼀个 Znode 节点拥有唯⼀的路径就像命名空间⼀样对不同信息作出清晰的隔离。
zk中的znode结构
zk中的znode包含了四个部分
data保存数据acl权限定义了什么样的用户能够操作这个节点且能够进行怎样的操作。 ccreate 创建权限允许在该节点下创建⼦节点wwrite 更新权限允许更新该节点的数据rread 读取权限允许读取该节点的内容以及⼦节点的列表信息ddelete 删除权限允许删除该节点的⼦节点aadmin 管理者权限允许对该节点进⾏acl权限设置 stat描述当前znode的元数据child当前节点的⼦节点
zk中节点znode类型
创建节点命令不同参数代表不同类型znode 持久节点: 创建出的节点在会话结束后依然存在。保存数据默认持久顺序节点: 创建出的节点根据先后顺序会在节点之后带上⼀个数值越后执行数值越⼤适用于分布式锁的应用场景- 单调递增-s临时节点 临时节点是在会话结束后自动被删除的通过这个特性zk可以实现服务注册与发现的效果。-e
如何维持心跳 临时顺序节点跟持久序号节点相同适⽤于临时的分布式锁。-esContainer节点3.5.3版本新增Container容器节点当容器中没有任何子节点该容器节点会被zk定期删除60s。-cTTL节点可以指定节点的到期时间到期后被zk定时删除。只能通过系统配置 zookeeper.extendedTypesEnabledtrue 开启-t【不稳定了解即可】
zk的数据持久化
zk的数据是运行在内存中zk提供了两种持久化机制
事务日志
zk把执行的命令以日志形式保存在dataLogDir指定的路径中的文件中如果没有指定 dataLogDir则按dataDir指定的路径。
数据快照
zk会在⼀定的时间间隔内做⼀次内存数据的快照把该时刻的内存数据保存在快照⽂件中。
【默认两种都是开启的】 zk通过两种形式的持久化在恢复时先恢复快照文件中的数据到内存中再用日志文件中的数据做增量恢复这样的恢复速度更快。
Zookeeper客户端(zkCli)的使用
启动客户端
启动客户端./zkCli.sh -server ip:port如果连接本地Zookeeperip:port可省略
./zkCli.sh退出客户端
quit常用命令 ls / 查看znode目录结构 help 帮助命令 创建Znode不同参数对应不同类型节点【不加参数默认持久节点】 存取设置数据 create /test abc 存get /test 取set /test abc 设置数据 普通查询 get /test ls / ls /test -R参数 递归查询 查看节点详细信息 get -s /test -s参数 cZxid: 创建节点的事务IDmZxid修改节点的事务IDpZxid添加和删除⼦节点的事务IDctime节点创建的时间mtime: 节点最近修改的时间dataVersion: 节点内数据的版本每更新⼀次数据版本会1aclVersion: 此节点的权限版本ephemeralOwner: 如果当前节点是临时节点该值是当前节点所有者的session id。如果节点不是临时节点则该值为零。 dataLength: 节点内数据的长度numChildren: 该节点的节点个数 删除节点
1、普通删除 节点不为空时直接用delete无法删除此时可以用deleteall进行删除 2、乐观锁删除 -v 参数
需要与节点详细信息dataVersion对应否则无法删除 权限设置 注册当前会话的账号和密码 addauth digest xiaowang:123456创建节点并设置权限 create /test-node abcd auth:xiaowang:123456:cdwra在另⼀个会话中必须先使用账号密码步骤一才能拥有操作该节点的权限
Curator客户端的使用
Curator介绍
Curator是Netflix公司开源的⼀套zookeeper客户端框架Curator是对Zookeeper支持最好的客户端框架。Curator封装了⼤部分Zookeeper的功能比如Leader选举、分布式锁等减少了技术人员在使用Zookeeper时的底层细节开发⼯作。
引入Curator
引入依赖 !--Curator--dependencygroupIdorg.apache.curator/groupIdartifactIdcurator-framework/artifactIdversion2.12.0/version/dependencydependencygroupIdorg.apache.curator/groupIdartifactIdcurator-recipes/artifactIdversion2.12.0/version/dependency!--Zookeeper--dependencygroupIdorg.apache.zookeeper/groupIdartifactIdzookeeper/artifactIdversion3.7.14/version/dependency配置文件
curator:retryCount: 5elapsedTimeMs: 5000connectString: 124.222.253.33:2181sessionTimeoutMs: 60000connectionTimeoutM: 5000注入配置Bean
Data
Component
ConfigurationProperties(prefix curator)
public class WrapperZK {private int retryCount;private int elapsedTimeMs;private String connectString;private int sessionTimeoutMs;private int connectionTimeoutMs;
}注⼊CuratorFramework
Configuration
public class CuratorConfig {AutowiredWrapperZK wrapperZk;Bean(initMethod start)public CuratorFramework curatorFramework() {return CuratorFrameworkFactory.newClient(wrapperZk.getConnectString(),wrapperZk.getSessionTimeoutMs(),wrapperZk.getConnectionTimeoutMs(),new RetryNTimes(wrapperZk.getRetryCount(), wrapperZk.getElapsedTimeMs()));}
}创建节点 AutowiredCuratorFramework curatorFramework; Testvoid createNode() throws Exception {// 添加持久节点String path curatorFramework.create().forPath(/curator-node);// 添加临时序号节点String path1 curatorFramework.create().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath(/curator-node, some-data.getBytes());System.out.printf(curator create node :%s successfully.%n, path);System.in.read();}获得节点数据 Testpublic void testGetData() throws Exception {byte[] bytes curatorFramework.getData().forPath(/curator-node);System.out.println(new String(bytes));}修改节点数据 Testpublic void testSetData() throws Exception {curatorFramework.setData().forPath(/curator-node, changed!.getBytes());byte[] bytes curatorFramework.getData().forPath(/curator-node);System.out.println(new String(bytes));}创建节点同时创建父节点 Testpublic void testCreateWithParent() throws Exception {String pathWithParent /node-parent/sub-node-1;String path curatorFramework.create().creatingParentsIfNeeded().forPath(pathWithParent);System.out.printf(curator create node :%s successfully.%n, path);}删除节点 Testpublic void testDelete() throws Exception {String pathWithParent /node-parent;curatorFramework.delete().guaranteed().deletingChildrenIfNeeded().forPath(pathWithParent);}zk实现分布式锁
zk中锁的分类
读锁大家都可以读要想上读锁的前提是之前的锁没有写锁 【读锁共享】写锁只有得到写锁的才能写。要想上写锁的前提是之前没有任何锁。 【写锁独占】
zk如何上读锁
创建⼀个临时序号节点节点的数据是read表示是读锁获取当前zk中序号比自己小的所有节点判断最小节点是否是读锁 如果不是读锁的话则上锁失败为最小节点设置监听。阻塞等待zk的watch机制会当最小节点发⽣变化时通知当前节点于是再执行第⼆步的流程如果是读锁的话则上锁成功 zk如何上写锁
创建⼀个临时序号节点节点的数据是write表示是写锁获取zk中所有的子节点判断自己是否是最小的节点 如果是则上写锁成功如果不是说明前面还有锁则上锁失败监听最小的节点如果最小节点有变化 则回到第⼆步。 羊群效应
如果用上述的上锁方式只要有节点发⽣变化就会触发其他节点的监听事件这样的话对 zk的压力⾮常⼤——羊群效应。可以调整成链式监听。解决这个问题。 监听当前节点的上一个节点即可。
curator实现读写锁
1获取读锁 Autowiredprivate CuratorFramework client; Testvoid testGetReadLock() throws Exception {// 读写锁InterProcessReadWriteLock interProcessReadWriteLock new InterProcessReadWriteLock(client, /lock1);// 获取读锁对象InterProcessLock interProcessLock interProcessReadWriteLock.readLock();System.out.println(等待获取读锁对象!);// 获取锁interProcessLock.acquire();for (int i 1; i 100; i) {Thread.sleep(3000);System.out.println(i);}// 释放锁interProcessLock.release();System.out.println(等待释放锁!);}2获取写锁 Testvoid testGetWriteLock() throws Exception {// 读写锁InterProcessReadWriteLock interProcessReadWriteLock new InterProcessReadWriteLock(client, /lock1);// 获取写锁对象InterProcessLock interProcessLock interProcessReadWriteLock.writeLock();System.out.println(等待获取写锁对象!);// 获取锁interProcessLock.acquire();for (int i 1; i 100; i) {Thread.sleep(3000);System.out.println(i);}// 释放锁interProcessLock.release();System.out.println(等待释放锁!);}zk的watch机制
Watch机制介绍
可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发⽣改变也就是调用了 create delete setData 方法的时候将会触发 Znode 上注册的对应事件 请求 Watch 的客户端会接收到异步通知。 客户端使用了NIO通信模式监听服务端的调用。
zkCli客户端使用watch
create /test xxx
get -w /test ⼀次性监听节点
ls -w /test 监听目录创建和删除子节点会收到通知。子节点中新增节点不会收到通知
ls -R -w /test 对于子节点中子节点的变化但内容的变化不会收到通知 get -w /test 监听节点 监听是一次性的监听当前节点内容变化无法监听子节点每次获取数据时都带-w参数可以实现持续监听节点 ls /w /test 监听节点目录变化可以监听子节点一级子节点加上-R参数可以递归监听所有子节点 curator客户端使用watch Testpublic void addNodeListener() throws Exception {NodeCache nodeCache new NodeCache(curatorFramework, /curator-node);nodeCache.getListenable().addListener(new NodeCacheListener() {Overridepublic void nodeChanged() throws Exception {log.info({} path nodeChanged: , /curator-node);printNodeData();}});nodeCache.start();System.in.read();}public void printNodeData() throws Exception {byte[] bytes curatorFramework.getData().forPath(/curator-node);log.info(data: {}, new String(bytes));}Zookeeper集群实战
Zookeeper集群角色
zookeeper集群中的节点有三种角色
Leader处理集群的所有事务请求可读可写集群中只有⼀个Leader。Follower只能处理读请求参与Leader选举。Observer只能处理读请求提升集群读的性能但不能参与Leader选举。 集群搭建
搭建4个节点其中⼀个节点为Observer
1创建4个节点的myid并设值
在/usr/local/zookeeper中创建以下四个文件
/usr/local/zookeeper/data/zk1# echo 1 myid
/usr/local/zookeeper/data/zk2# echo 2 myid
/usr/local/zookeeper/data/zk3# echo 3 myid
/usr/local/zookeeper/data/zk4# echo 4 myid2编写4个zoo.cfg
# The number of milliseconds of each tick
tickTime2000
# The number of ticks that the initial
# synchronization phase can take
initLimit10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit5
# 修改对应的zk1 zk2 zk3 zk4
dataDir/usr/local/zookeeper/data/zk1
# 修改对应的端⼝ 2181 2182 2183 2184
clientPort2181
# 2001为集群通信端⼝3001为集群选举端⼝observer表示不参与集群选举
server.1124.222.253.33:2001:3001
server.2124.222.253.33:2002:3002
server.3124.222.253.33:2003:3003
server.4124.222.253.33:2004:3004:observer# 上述配置启动zk时无法监听端口可以加下面一行配置解决 监听所有网卡
quorumListenOnAllIPstrue3启动4台Zookeeper
./bin/zkServer.sh start ../conf/zoo1.cfg
./bin/zkServer.sh start ../conf/zoo2.cfg
./bin/zkServer.sh start ../conf/zoo3.cfg
./bin/zkServer.sh start ../conf/zoo4.cfg查看集群状态
./bin/zkServer.sh status ../conf/zoo1.cfg
./bin/zkServer.sh status ../conf/zoo2.cfg
./bin/zkServer.sh status ../conf/zoo3.cfg
./bin/zkServer.sh status ../conf/zoo4.cfg连接Zookeeper集群
./bin/zkCli.sh -server 124.222.253.33:2181,124.222.253.33:2182,124.222.253.33:2183,124.222.253.33:2184ZAB协议
什么是ZAB协议
zookeeper作为非常重要的分布式协调组件需要进行集群部署集群中会以⼀主多从的形式进行部署。zookeeper为了保证数据的⼀致性使用了ZABZookeeper Atomic Broadcast 原子消息广播协议这个协议解决了Zookeeper的崩溃恢复和主从数据同步的问题。 ZAB协议定义的四种节点状态
Looking 选举状态。Following Follower 节点从节点所处的状态。Leading Leader 节点主节点所处状态。Observing观察者节点所处的状态。
集群上线时的Leader选举过程
Zookeeper集群中的节点在上线时将会进⼊到Looking状态也就是选举Leader的状态具体过程如下 选票格式
myid | zXid
myidmyid文件配置数字
zXid事务id记录节点数据变化次数增删改操作
崩溃恢复时的Leader选举
Leader建立完后Leader周期性地不断向Follower发送心跳ping命令没有内容的 socket。当Leader崩溃后Follower发现socket通道已关闭于是Follower开始进⼊到 Looking状态重新回到上⼀节中的Leader选举过程Leader选举期间集群不能对外提供服务。
主从服务器之间的数据同步 一定是主节点写数据client连接到从节点也是发给主节点写数据
半数以上【相对于集群数量】说明集群网络是没问题的为了提高集群写数据的性能
Zookeeper中的NIO与BIO的应用 NIO 用于被客户端连接的2181端口使用的是NIO模式与客户端建立连接客户端开启Watch时也使用NIO等待Zookeeper服务器的回调 BIO 集群在选举时多个节点之间的投票通信端口使用BIO进行通信心跳机制
CAP理论
CAP 定理
2000 年 7月加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后麻省理⼯学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后 CAP理论正式成为分布式计算领域的公认定理。
CAP 理论为⼀个分布式系统最多只能同时满足一致性Consistency、可⽤性 Availability和分区容错性Partition tolerance这三项中的两项。
一致性Consistency【数据一致】
⼀致性指 “all nodes see the same data at the same time”即更新操作成功并返回客户端完成后所有节点在同⼀时间的数据完全⼀致。
可用性Availability【服务可用】
可用性指“Reads and writes always succeed”即服务⼀直可用而且是正常响应时间。
分区容错性Partition tolerance【分布式系统必须满足】
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”即分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供满足⼀致性或可⽤性的服务。——避免单点故障就要进行冗余部署冗余部署相当于是服务的分区这样的分区就具备了容错性。
CAP 权衡
通过 CAP 理论我们知道⽆法同时满足⼀致性、可用性和分区容错性这三个特性那要舍弃哪个呢
对于多数大型互联网应用的场景主机众多、部署分散而且现在的集群规模越来越大所以节点故障、网络故障是常态而且要保证服务可用性达到 N 个 9即保证 P 和 A舍弃 C退而求其次保证最终⼀致性。虽然某些地方会影响客户体验但没达到造成用户流失的严重程度。
对于涉及到钱财这样不能有⼀丝让步的场景C 必须保证。网络发生故障宁可停止服务这是保证 CA舍弃 P。还有⼀种是保证 CP舍弃 A。例如网络故障是只读不写。
孰优孰略没有定论只能根据场景定夺适合的才是最好的! BASE 理论
eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结在 ACM 上发表⽂章提出 BASE 理论BASE 理论是对 CAP 理论的延伸核心思想是即使无法做到强⼀致性Strong ConsistencyCAP 的⼀致性就是强⼀致性但应用可以采用适合的方式达到最终⼀致性 Eventual Consitency。
基本可用Basically Available BA
基本可用指分布式系统在出现故障的时候允许损失部分可用性即保证核心可用。
电商大促时为了应对访问量激增部分用户可能会被引导到降级页面服务层也可能只提供降级服务。这就是损失部分可用性的体现。
软状态Soft State S
软状态是指允许系统存在中间状态而该中间状态不会影响系统整体可⽤性。分布式存储中⼀般⼀份数据至少会有三个副本允许不同节点间副本同步的延时就是软状态的体现。mysql replication 的异步复制也是⼀种体现。
最终一致性Eventual Consistency E
最终⼀致性是指系统中的所有数据副本经过⼀定时间后最终能够达到⼀致的状态。弱⼀致性和强⼀致性相反最终⼀致性是弱⼀致性的⼀种特殊情况。
Zookeeper追求的一致性
Zookeeper在数据同步时追求的并不是强⼀致性而是顺序⼀致性事务id的单调递增。
zk追求CP原则但也不是强一致性集群半数以上ACK而是顺序一致性。
Curator客户端相关代码https://github.com/lkl778/zk.git
