先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Linux运维全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上运维知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注运维)
正文
server.5 = 127.0.0.1:2692:3792
server.6 = 127.0.0.1:2693:3793
server.5的zoo.cfg配置
peerType=observer
server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790
server.4 = 127.0.0.1:2691:3791
server.5 = 127.0.0.1:2692:3792:observer
server.6 = 127.0.0.1:2693:3793
server.6的zoo.cfg配置
peerType=observer
server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790
server.4 = 127.0.0.1:2691:3791
server.5 = 127.0.0.1:2692:3792
server.6 = 127.0.0.1:2693:3793:observer
server.4
、server.5
、server.6
分别启动,数据就可以从源集群同步到目的集群了,即使现在源集群有写操作,也可以实时同步。
-
如下是
server.4
作为源集群的Observer启动时的日志: -
server.4
刚启动时,是一个LOOKING
状态,就是在找Leader
。 -
找到
Leader
以后,就变成了OBSERVING
状态。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hXDEN6rq-1632664267904)(C:\我的坚果云\mymd\image\zk_observer1.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t7sErJxi-1632664267907)(C:\我的坚果云\mymd\image\zk_observer2.png)]
2、切换客户端zk地址
虽然server.4
、server.5
、server.6
都是Observer
,但是也可以对外提供服务。此时可以将连接目的集群的客户端,如qconf_agent
、kafka
中的zk地址修改为目的集群的。
3、修改目的集群配置
先将目的集群的配置observer
相关的配置去掉,都修改为如下配置:
server.4 = 127.0.0.1:2691:3791
server.5 = 127.0.0.1:2692:3792
server.6 = 127.0.0.1:2693:3793
4、依次重启目的集群
目的集群的配置修改好了,还没有重启,此时依然是作为Observer在对外提供服务。
现在依次重启server.4
、server.5
,server.5
成为目的集群的Leader
,此时已经完全和源集群分离,立刻重启server.6
,server.6
作为Follower
加入目的集群。
但是在目的集群重启Leader选举时,可能存在短暂的数据不一致,因为可能在server.5
重启触发Leader选举时,server.6
可能接收到写请求,依然转发给源Leader,所以server.6
甚至是整个目的集群都尽快完成重启。
到这里基本就完成了集群的不停机动态迁移,观察一段时间目的集群的服务状态,如果正常,就可以把源集群停掉了。
这过程一旦出现问题,比如目的集群重启失败,立刻回滚第二步,然后查看目的集群的启动日志。
zk集群的扩容,对读请求来说是可以提升性能,但是对于写请求就未必是好事了,因为所有的写请求都需要Leader统一协调处理(两阶段提交),所以服务节点多了反而会降低写性能。
zk集群的扩容可以有两种形式,一种是扩容节点以Observer
附庸在源集群上,另一种就是正常意义上扩容,给源集群加Follower
节点。
依然用一台服务器搭建的伪集群演示。
1、Observer扩容
以Observer
方式扩容,不参与源集群的投票和过半机制,依然可以一起加入到zk地址中对外提供服务,有如下几个优点:
-
提升源集群的读性能,对写性能影响很小。
-
可以将Observer部署在异地机房,读请求就近发送,降低延迟。
但是多多少少对写操作有一定影响,即Observer
所在服务,处于无监管状态,无法确保数据都同步了,可能因为网络原因一些请求被丢弃等,需要对Observer
进行监控。如果Observer
部署在异地,写同步的延迟可能也会增加。
Observer
扩容还有一个缺点,就是源集群的稳定性没有提高。
假设扩容的Observer服务为server.4
,只需要在其zoo.cfg
中如下配置即可:
server.4的zoo.cfg配置
peerType=observer
server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790
server.4 = 127.0.0.1:2691:3791:observer
2、Follower扩容
Follower扩容建议扩容服务节点数为偶数个,这样和源集群加起来就是奇数个。
在不停机,只有Leader重选时不能正常对外提供服务外,集群一直处于正常状态,照这个要求,试了多种场景,好像只有一种方式:新节点作为Follower加入源集群。
假设,源集群为3个服务节点,Leader为server.1
,现在扩容为5个,扩容节点为server.7
和 server.8
。源集群初始配置为:
server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790
(1)修改扩容节点配置
修改server.7
和 server.8
的zoo.cfg
为如下所示:
server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790
server.7 = 127.0.0.1:2697:3797
server.8 = 127.0.0.1:2698:3798
(2)启动扩容节点
server.7
和 server.8
依次启动后,首先处于投票选举的状态(LOOKING
),交换选票,收到源集群 Follower
和 Leader
的选票后,统计选票,如果某个节点拥有超半数的选票,且有Leader
,则扩容节点设置自己的状态为Follower
(FOLLOWING
),并退出选举。这样扩容节点就和源集群建立了连接。
但是源集群保持独立,新节点故障与否不影响源集群过半机制判断。
(3)修改客户端zk地址
修改连接源集群的客户端的zk地址为加上server.7
和 server.8
共5个ipport
。
(4)修改源集群的配置
依次修改源集群的zoo.cfg
,加上server.7
和 server.8
。
(5)重启源集群
依次重启源集群,但是需要注意源集群的Leader最后重启,如server.1是Leader,就先重启server.2,再重启server.3,此时源集群处于不可用和扩容之后的新集群处于Leader选举的状态,此时会有短暂不能正常对外提供服务。
最后重启server.1
。扩容完毕。
需要注意:扩容之后的集群的Leader变了,可能为扩容节点中的一个。
(6)人为脑裂
需要强调一下,如果扩容的节点数超过了源集群的节点个数,可能人为造成脑裂。
如3个扩容为7个,需要扩容4个节点,使用如上方式扩容时,就可能出现问题。扩容节点依次重启时,处于投票选举状态,交换选票,收到源集群 Follower
和 Leader
的选票后,统计选票,源集群有3个节点投给了某个节点,但是扩容之后的节点个数为7,3没有超过7的半数,所以扩容节点不会设置自己的状态为Follower
(FOLLOWING
),一直处于投票选举状态。
需要强调两点:
-
处于投票状态的服务节点接收到其他节点的选票时,会根据选票信息中发送者状态来区分统计,
Follower
和Leader
发送的一起统计,同处于投票状态(LOOKING
)的节点一起统计。 -
统计选票时,如果是
Follower
或Leader
发来的选票,说明此时集群中已经有Leader
了,但是还是先判断票数是否过半,然后再判断集群中是否有Leader
。
当4个扩容节点都重启后,4个扩容节点交换选票,可以再选一个Leader
出来,此时就存在两个Leader
,互不干扰。源集群没有重启过还是认为自己是3个节点的,而扩容之后的集群,认为自己是7个节点,但是只有4个正常节点,挂一个就会死。
脑裂出现了,可能会出现数据不一致问题。
正常情况下,ZooKeeper
不会因为网络分区出现脑裂问题。
因为扩容有两种方式,对应的缩容也有两种应对措施:
-
缩减掉Observer很简单,基本不会影响源集群。
-
缩减Follower,就稍微复杂些。
以源集群5个节点缩减为3个为例,源集群配置为:
server.1 = 127.0.0.1:2688:3788
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注运维)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
Observer很简单,基本不会影响源集群。
- 缩减Follower,就稍微复杂些。
以源集群5个节点缩减为3个为例,源集群配置为:
server.1 = 127.0.0.1:2688:3788
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注运维)
[外链图片转存中…(img-me2NZAQu-1713190853908)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!