企业官网建设流程全解析

网站建设成本预算,深圳专业优定软件网站建设,抖音搜索引擎优化,用织梦做领券网站一 : zookeeper介绍 概念#xff1a; zookeeper他是一个分布式协调组件 使用场景1#xff1a;分布式协调组件使用场景2#xff1a;分布式锁 ​ zk在实现分布式锁上#xff0c;可以做到强一致性#xff0c;关于分布式锁的相关知识#xff0c;会在之后的ZAB协议中介绍 使用…一 : zookeeper介绍概念 zookeeper他是一个分布式协调组件使用场景1分布式协调组件使用场景2分布式锁​ zk在实现分布式锁上可以做到强一致性关于分布式锁的相关知识会在之后的ZAB协议中介绍使用场景3无状态化的实现二 : zookeeper内部数据模型1.0 z-node结点——数据类型# 1.0 启动zookeeper[rootaliyun ~]# /usr/local/zookeeper/bin/zkServer.sh start# 2.0 进入zkcli/usr/local/zookeeper/bin/zkCli.sh# 3.0 创建结点[zk: localhost:2181(CONNECTED)0]ls/[zookeeper][zk: localhost:2181(CONNECTED)1]create /text1 Created /text1[zk: localhost:2181(CONNECTED)2]ls/[text1, zookeeper][zk: localhost:2181(CONNECTED)3]# 4.0 Zookeeper的数据模型是什么样子呢类似于数据结构中的树同时也很像文件系统的目录# 5.0 树是由节点所组成Zookeeper的数据存储也同样是基于节点这种节点叫做Znode但是不同于树的节点Znode的引用方式是路劲引用类似于文件路径2.0 znode节点——组成部分zk中的node包含四个部分组件说明data节点存储的数据stat节点元数据版本号、时间、zxid 等ACL权限控制children子节点列表[zk: localhost:2181(CONNECTED)3]create /text2 abc Created /text2[zk: localhost:2181(CONNECTED)4]get /text2 abc[zk: localhost:2181(CONNECTED)5]3.0 znode节点——持久节点和持久序号节点节点类型是否自动删除是否自动编号典型用途持久节点❌ 不删除❌ 不编号配置、注册中心目录持久序号节点❌ 不删除✔ 自动编号排队、分布式锁、唯一序号# 1.0 创建持久节点[zk: localhost:2181(CONNECTED)5]create /text3 Created /text3# 2.0 创建持久序号节点[zk: localhost:2181(CONNECTED)6]create -s /text4 Created /text40000000003[zk: localhost:2181(CONNECTED)7]4.0 znode节点——临时节点实现原理以及应用场景临时节点临时节点是在会话结束后自动被删除的通过这个特性zk可以实现服务注册与发现的效果临时序号节点 类比于持久序号节点# 1.0 创建临时节点[zk: localhost:2181(CONNECTED)7]create -e /text5 bb Created /text5# 2.0 创建临时序号节点[zk: localhost:2181(CONNECTED)8]create -e -s /text6 cc Created /text60000000005[zk: localhost:2181(CONNECTED)9]5.0 znode节点——其他类型# 1.0 container节点 当容器中无任何子节点时候 该容器会被zk定期删除[zk: localhost:2181(CONNECTED)9]create -c /mycontainer# 这个容器中没有子节点会被定期删除Created /mycontainer[zk: localhost:2181(CONNECTED)10]# 2.0 TTL节点可以指定节点的到期时间到期后被zk定时删除。只能通过系统配置zookeeper.extendedTypeEnableetrue开启6.0 zk持久化——数据持久化方案zk中的数据是运行在内存当中的zk提供了两种持久化机制# 1.0 第一种 事务日志 一般放在以下下面[rootaliyun ~]# cd /usr/local/zookeeper/data[rootaliyun data]# lltotal0[rootaliyun data]## 2.0 数据快照# 3.0 原因恢复时我们先恢复快照文件到内存中 然后再用日志文件中的数据进行增量备份 这两种结合恢复的速度更快。三 : zookeeper客户端zkcli的使用1.0 创建和查询节点# 1.0 创建持久节点/持久序列节点[zk: localhost:2181(CONNECTED)2]create /text7 Created /text7[zk: localhost:2181(CONNECTED)3]create -s /text7 Created /text70000000008# 2.0 创建临时节点/临时序列节点[zk: localhost:2181(CONNECTED)5]create -e /text9 Created /text9[zk: localhost:2181(CONNECTED)6]create -e -s /text9.1 Created /text9.10000000010[zk: localhost:2181(CONNECTED)7]# 3.0 查询[zk: localhost:2181(CONNECTED)7]ls/text7[][zk: localhost:2181(CONNECTED)8]# 4.0 递归查询[zk: localhost:2181(CONNECTED)8]ls-R /text7 /text7[zk: localhost:2181(CONNECTED)9]# 5.0 获取节点的数据[zk: localhost:2181(CONNECTED)10]get /text7 null[zk: localhost:2181(CONNECTED)11]# 6.0 获取详细信息[zk: localhost:2181(CONNECTED)9]get -s /text7 null cZxid0xd ctimeMon Nov1715:54:00 CST2025mZxid0xd mtimeMon Nov1715:54:00 CST2025pZxid0xd cversion0dataVersion0aclVersion0ephemeralOwner0x0 dataLength0numChildren0[zk: localhost:2181(CONNECTED)10]2.0 乐观锁的删除乐观锁的定义他是一种并发控制机制。 多个客户端并发修改同一个节点不会经常冲突。核心 ZooKeeper 的每次更新操作都必须带上版本号如果版本号不一致则更新失败从而实现乐观锁[zk: localhost:2181(CONNECTED)37]create /text1 Created /text1[zk: localhost:2181(CONNECTED)38]delete -v1 /text1 version No is not valid:/text1[zk: localhost:2181(CONNECTED)39]delete -v0 /text1[zk: localhost:2181(CONNECTED)40]3.0 权限设置acl权限定义了哪个用户可以操作怎样操作# 1.0 zk窗口1# 添加权限addauth digest xiaoming:123456# 创建节点并给予权限create /text-node abc auth:xiaoming:123456:cdrwa# 拿数据get /text-node# 2.0 zk窗口2# 拿数据: 这里我们可以发现是失败的get /text-node# 增加权限addauth digest xiaoming:123456# 拿数据此时我们发现成功get /text-node四 : zk实现分布式锁(难)1.0 读锁和写锁的概念读锁 任何人都可以读锁(前提是没有得到写锁)写锁 只要得到写锁的才能写(前提是没有任何锁)类比读锁 约会写锁 结婚2.0 如何上读锁✅ 一、ZK 中加读锁的核心思想读锁 允许多个读同时存在但不能与写锁同时存在。ZK 本身没有“读锁”命令你需要通过临时顺序节点节点命名规则实现。✅ 二、步骤记住这个流程就能在面试上说出来1创建临时顺序节点一般路径/lock/read-0000001 /lock/read-0000002 /lock/write-0000001你要“上读锁”就创建/lock/read-xxxxxx 临时顺序节点2判断是否可以获得读锁最关键你创建了一个读锁节点比如/lock/read-0000008然后你查看比你小的所有节点getChildren /lock你要检查是否有 “比你小的写锁” 节点存在如果没有比你序号更小的 write-xxxx 节点→ 你可以直接获得读锁如果有比你小的写锁节点→ 你不能获得读锁需要等待3监听前一个写锁节点如果你不能立即上读锁找到比你小的最近的写锁节点序号最接近watch它当它删除写锁释放 → 你再重新判断→ 直到获取锁 三、举例帮助你理解面试讲这个非常加分当前 /lock 下有write-0000001 read-0000002 write-0000003你创建了read-0000004你看“比你序号小的节点”write-0000001 ✔阻塞read-0000002不影响读锁write-0000003 ✔阻塞因为存在比你序号小的写锁节点 →不能获得读锁你要监听最接近你的写锁→watch write-0000003它删除后你再判断是否可以继续获取。 四、面试 30 秒回答版本ZK 中读锁是基于临时顺序节点实现的。读写锁节点统一放在一个目录下比如 /lock。上读锁时客户端创建一个 read- 前缀的临时顺序节点。然后检查所有比自己小的节点如果没有 write- 的节点存在就获得读锁如果存在比自己小的 write 节点就 watch 那个最近的写锁节点等它删除后再尝试。所以读锁可以共享但必须等所有更早的写锁释放后才能获取。3.0 如何上写锁✅ 一、ZK 中如何上写锁Write Lock写锁 独占锁必须保证前面没有任何节点无论读、写。写锁流程和读锁很像只是判断条件更严格。 二、写锁获取流程记住这 3 步就够了1创建临时顺序节点路径一般是/lock/write-0000001步骤create -e -s /lock/write-2检查自己是不是当前序号最小的节点列出所有节点ls/lock假设你创建的是write-0000008你检查所有节点中比你序号小的节点是否存在如果没有比你小的节点 → 你获得写锁如果有 → 你阻塞等待不能获取写锁⚠️ 注意这里不区分 read/write只要有人比你早排队你就不能上写锁。写锁必须严格排队确保独占。3监听“比你小的最近的节点”如果你的写锁不是最小节点比如read-0000005 write-0000003 read-0000007 write-0000008你的你要监听不是所有比你小的节点而是距离你最近的那个节点read-0000007当那个节点删除后你重新判断。 面试回答如何在 ZK 中上写锁写锁基于临时顺序节点实现。客户端创建 write- 前缀的临时顺序节点然后列出所有子节点。只要存在比自己序号小的任何节点包括读节点和写节点写锁就不能获得。客户端会 watch 那个最接近自己的前一个节点等它删除后再次判断。最小节点即可获得写锁。4.0 羊群效应这个是 ZK 面试必考点1.0 什么是羊群效应本质大量客户端同时 watch 同一个节点一旦该节点删除所有客户端同时被唤醒 → 瞬间并发压力巨大。像一群羊挤着门口只要门开一点全冲出去。2.0 在 ZK 锁场景中可能出现如果所有客户端都 watch/lock或某个相同的节点那么一释放锁全都被唤醒 → 群体抖动。 3.0 ZK 如何避免羊群效应ZK 官方推荐方案每个节点只 watch 排在自己前面的那个节点。优点只唤醒一个客户端事件传播像链式传递不会所有客户端一起被唤醒例如节点1, 2, 3, 4, 5每个节点 watch 自己前一个2 watch 13 watch 24 watch 35 watch 4当 1 删除时只唤醒 22 获得锁后删除删除触发 3依次类推完全避免羊群效应。4.0 ⭐ 面试回答什么是羊群效应如何避免羊群效应就是大量客户端同时监听同一个节点一旦这个节点变化就导致所有客户端被唤醒增加服务器压力。ZooKeeper 通过“只监听自己前一个节点”的方式避免羊群效应使事件从前往后逐个传递而不是全部客户端一起触发。五 : zk的watch机制1.0 原理介绍客户端(zkcli,Curator)有一个功能监听节点的变化# 1.0 客户端1创建一个节点。并设置监听节点值的变化[zk: localhost:2181(CONNECTED)8]create /text8 Created /text8[zk: localhost:2181(CONNECTED)9]get -w /text8 null[zk: localhost:2181(CONNECTED)10]# 2.0 客户端2设置节点的值[zk: localhost:2181(CONNECTED)2]set/text8 bbb# 3.0 我们在客户端1中取这个值[zk: localhost:2181(CONNECTED)10]WATCHER:: WatchedEvent state:SyncConnected type:NodeDataChanged path:/text8 get /text8 bbb# 4.0 我们在客户端2中任然进行修改[zk: localhost:2181(CONNECTED)3]set/text8 ccc# 5.0 此时我们发现触发不了watch机制了因为监听他是一次的。 如果想要改变这个情况我们把第三步改以下,换成以下的情况get -w /text82.0 zkcli实现watchcreate /text xxxx# 创建节点get -w /text# 一次性监听节点ls-w /text# 监听目录ls-R -w /text# 监听目录中子节点的变化六 : zookeeper集群1.0 节点的角色leader: 主节点Follower:从节点Observer:观察者2.0 集群搭建及连接1.0 创建myid 文件其中有一个节点是Observer/usr/local/zookeeper/zkdata/zk1# echo 1 myid/usr/local/zookeeper/zkdata/zk2# echo 2 myid/usr/local/zookeeper/zkdata/zk3# echo 3 myid/usr/local/zookeeper/zkdata/zk4# echo 4 myid2.0 编写四个zoo.cfg其中需要改的是​ myid的路径端口号ip# The number of milliseconds of each ticktickTime2000# The number of ticks that the initial# synchronization phase can takeinitLimit10# The number of ticks that can pass between# sending a request and getting an acknowledgementsyncLimit5# the directory where the snapshot is stored.# do not use /tmp for storage, /tmp here is just# example sakes. 修改对应的zk1 zk2 zk3 zk4dataDir/usr/local/zookeeper/zkdata/zk1# the port at which the clients will connectclientPort2181#2001为集群通信端口3001为集群选举端口observer观察者身份server.1192.168.200.128:2001:3001 server.2192.169.200.128:2002:3002 server.3192.168.200.128:2003:3003 server.4192.168.200.128:2004:3004:observer3.0 启动[rootaliyun bin]# ./zkServer.sh start ../conf/zoo1.cfg[rootaliyun bin]# ./zkServer.sh start ../conf/zoo2.cfg[rootaliyun bin]# ./zkServer.sh start ../conf/zoo3.cfg[rootaliyun bin]# ./zkServer.sh start ../conf/zoo4.cfg七 : ZAB协议1.0 ZAB协议介绍ZAB协议简称原子广播协议解决 zk的崩溃恢复和主从数据同步问题四种节点状态looking: 选举Following从节点所处的位置leading: 主节点所处的位置observing观察者所处的位置2.0 集群启动时leader的选举过程总结ZooKeeper 先比较各节点的 ZXID数据最新程度ZXID 最大的节点优先如果相同再比较 服务器ID。各节点不断交换投票当某个节点获得 超过半数的支持 时当选 Leader。ZooKeeper 的 Leader 选举在 第一次启动 或 Leader 崩溃 时发生。 假设有3台节点1,2,3每个节点都要选出一个 Leader。# 一、每个节点刚启动时的状态节点初始状态都是LOOKING 每个节点会向所有其他节点广播自己的投票 内容包含(服务器ID, ZXID)服务器ID 越大优先级越高 ZXID 越新值越大优先级越高# 二、选举的比较规则核心ZooKeeper 使用如下规则决定谁当 Leader ZXID 最大者优先 如果 ZXID 一样服务器ID 最大者优先 → 谁的“数据最新 ID 最大”谁最有资格当 Leader。# 三、交换投票的过程每个节点先“投给自己” 每个节点收到别人的投票后会比较 如果对方的ZXID, ID比自己投票更优 → 更新投票为对方 将新的投票再次广播出去# 四、达成多数派Quorum当某一个候选人例如节点3获得超过半数的票如3节点中得到2票则 节点3成为LEADING 其他节点变为FOLLOWING 一个 Leader 选举就完成了。3.0 崩溃恢复时的leader选举Leader建立完后Leader周期性地不断向Follower发送心跳ping命令没有内容的socket。当Leader崩溃后Follower发现socket通道已关闭于是Follower开始进入到Looking状态重新回到上一节中的Leader选举状态此时集群不能对外提供服务。4.0 主从数据同步原理请问为啥要半数以上呢​ 答保证高效请问这个半数指的对象是集群整个还是从节点呢​ 答是集群整个5.0 NIO和BIO的应用场景NIO用于被客户端连接的2181端口使用的是NIO模式与客户端建立连接客户端开启Watch时也使用NIO等待Zookeeper服务器的回调BIO集群在选举时多个节点之间的投票通信端口使用BIO进行通信八 : CAP理论1.0 CAP介绍概念在一个分布式系统中一致性C、可用性A、**分区容错性P**三者不能同时完全满足只能同时满足其中两个。一致性读到的数据必须是最新正确的可用性请求一定有响应分区容错性网络一旦分裂系统不能崩2.0 BASE定理BASE 理论基本可用、软状态、最终一致BASE 理论是对 CAP 中AP 系统的一种实现思想强调牺牲强一致性换取高可用性和可扩展性。(1) 基本可用Basically Available​ 系统在出现故障时整体可用但可能有降级。​ 例如高峰期访问慢一点、部分功能被限流但系统不挂。(2) 软状态Soft State​ 系统中的数据允许在一段时间内不同步节点状态不是强一致的。​ 例如副本数据不同步允许“短暂脏读”。(3) 最终一致性Eventual Consistency​ 虽然不能保证“实时一致”但经过一定时间后所有副本最终会达到一致。​ 例如异步同步、副本延迟最后一定一致。(4) 一句话总结面试最常用BASE 理论是分布式系统在 CAP 中选择 AP 的落地方案牺牲强一致性换取高可用性允许数据短暂不一致但最终会一致。3.0 zookeeper追求的一致性​ Zookeeper在数据同步时追求的并不是强一致性而是顺序一致性事务id的单调递增1.0 CAP介绍概念在一个分布式系统中一致性C、可用性A、**分区容错性P**三者不能同时完全满足只能同时满足其中两个。一致性读到的数据必须是最新正确的可用性请求一定有响应分区容错性网络一旦分裂系统不能崩[外链图片转存中…(img-9NE1Jb89-1765536119292)]2.0 BASE定理BASE 理论基本可用、软状态、最终一致BASE 理论是对 CAP 中AP 系统的一种实现思想强调牺牲强一致性换取高可用性和可扩展性。(1) 基本可用Basically Available​ 系统在出现故障时整体可用但可能有降级。​ 例如高峰期访问慢一点、部分功能被限流但系统不挂。(2) 软状态Soft State​ 系统中的数据允许在一段时间内不同步节点状态不是强一致的。​ 例如副本数据不同步允许“短暂脏读”。(3) 最终一致性Eventual Consistency​ 虽然不能保证“实时一致”但经过一定时间后所有副本最终会达到一致。​ 例如异步同步、副本延迟最后一定一致。(4) 一句话总结面试最常用BASE 理论是分布式系统在 CAP 中选择 AP 的落地方案牺牲强一致性换取高可用性允许数据短暂不一致但最终会一致。3.0 zookeeper追求的一致性​ Zookeeper在数据同步时追求的并不是强一致性而是顺序一致性事务id的单调递增