ZooKeeper启动过程

1.如何启动

zkServer.sh【Linux】或 zkServer.cmd【Windows】

以zkServer.cmd为例(zkServer.sh中内容太多):

可以清晰的看出:调用了QuorumPeerMain这个类,传的参数为%ZOOCFG%【在zkEnv.cmd中定义,就是zoo.cfg】。

到QuorumPeerMain类中一看,果然有个main方法,且接受一个参数【配置文件路径】:

当然,接受的参数不是一个也没关系,只不过就不能集群了,只能以单机模式运行。仅当接受一个参数作为配置文件路径,且此配置文件没有设置为单机模式,才会开启ZooKeeper集群启动过程【上图120行,runFromConfig】。

2.启动过程源码分析

runFromConfig:

可以看出,程序转移到了QuorumPeer,首先设置一系列zoo.cfg中的属性值,而后start,QuorumPeer继承了Thread类,自然转到了QuorumPeer.run()。

run方法太长了,精简了一下,只留了骨架:

 @Override
    public void run() {
    	/// JMX...
        try {
            /*
             * Main loop
             */
            while (running) {
                switch (getPeerState()) {
                case LOOKING:
                    /// ...
                	setCurrentVote(makeLEStrategy().lookForLeader());
                	/// ...
                    break;
                case OBSERVING:
                    try {
                        setObserver(makeObserver(logFactory));
                        observer.observeLeader();
                    } catch (Exception e) {
                    } finally {
                        observer.shutdown();
                        setObserver(null);
                        updateServerState();
                    }
                    break;
                case FOLLOWING:
                    try {
                        setFollower(makeFollower(logFactory));
                        follower.followLeader();
                    } catch (Exception e) {
                    } finally {
                       follower.shutdown();
                       setFollower(null);
                       updateServerState();
                    }
                    break;
                case LEADING:
                    try {
                        setLeader(makeLeader(logFactory));
                        leader.lead();
                        setLeader(null);
                    } catch (Exception e) {
                    } finally {
                        if (leader != null) {
                            leader.shutdown("Forcing shutdown");
                            setLeader(null);
                        }
                        updateServerState();
                    }
                    break;
                }
            }
        } finally {
            /// clear JMX
        }
    }

可以看出,只要没有stop或者没有异常抛出,这个线程便一直在运行,没有后续更多的操作了,全部在这个循环里。

到此为止,ZooKeeper集群中的这一个节点【Peer】启动完毕。

从run()方法可以清晰的看到,ZooKeeper中的节点可以有四种状态:

  • LOOKING
  • OBSERVING
  • FOLLOWING
  • LEADING

其中,getPeerState()方法中state初始化为LOOKING,因此每一个节点启动时的状态都是LOOKING。

下一步,就是参与投票,选出ZooKeeper集群的Leader,见下篇文章:ZooKeeper FastLeaderElection算法。

时间: 2024-10-20 20:23:53

ZooKeeper启动过程的相关文章

ZooKeeper启动过程2:FastLeaderElection

前一篇文章中说到,启动ZooKeeper集群时,需要分别启动集群中的各个节点,各节点以QuorumPeer的形式启动,最后到达startLeaderElection和lookForLeader. 先说startLeaderElection 首先,初始化节点自身的currentVote[当前投票]为[myid.zxid.currentEpoch] 然后,初始化选举算法createElectionAlgorithm,默认使用FastLeaderElection算法,在这里,启动两个线程WorkerS

Openstack liberty中nova-compute服务的启动过程

前段时间撰文分析了"云主机的启动过程"源码,读者应该注意到了nova-scheduler,nova-compute等组件是通过发起rpc.cast, rpc.call调用完成交互的.那今天我打算介绍下nova-compute服务的启动过程,并重点分析下其与AMQP(rabbitmq)链接的建立过程. 在CentOS 7中启动nova-compute服务,执行路径是这样的: systemctl start openstack-nova-compute.service -> /usr

tomcat启动过程报the JDBC Driver has been forcibly unregistered问题的修复过程

最近两天在整理关于flume的总结文档,没有启动过tomcat.昨天晚上部署启动,发现报了如题的错误,全文如下: 严重: The web application [/oa-deploy] registered the JBDC driver [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web application was stopped. To prevent a mem

Linux启动过程笔记

Linux启动过程 1.启动流程(BIOS->MBR:Boot Code->引导GRUB->加载内核->执行init->runlevel) 2./boot/grub/下有多个文件   其中stage1为MBR镜像(512字节) stage2为引导程序 3./boot/grub/grub.conf为引导的配置文件 default=0#默认加载下边哪个系统 timeout=3#引导等待时间 splashimage=(hd0,1)/boot/grub/splash.xpm.gz#引

SpringMVC启动过程

1.  对于一个web应用,其部署在web容器中,web容器提供一个其一个全局的上下文环境,这个上下文环境就是ServletContext,它为后面的spring IoC容器提供宿主环境: 2.  web.xml中有配置ContextLoaderListener,也可以自定义一个实现ServletContextListener接口的Listener方法,web.xml中的配置实例如下: <listener> <listener-class>com.manager.init.Syst

Linux内核分析 实验三:跟踪分析Linux内核的启动过程

贺邦 + 原创作品转载请注明出处 + <Linux内核分析>MOOC课程 http://mooc.study.163.com/course/USTC-1000029000 一. 实验过程 1.打开shell,输入启动指令,内核启动完成后进入menu程序,支持三个命令help.version和quit. 2.然后使用gdb跟踪调试内核,输入命令qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S 3.按住

systemd启动过程

理解Linux启动过程 在我们打开Linux电脑的电源后第一个启动的进程就是init.分配给init进程的PID是1.它是系统其他所有进程的父进程.当一台Linux电脑启动后,处理器会先在系统存储中查找BIOS,之后BIOS会检测系统资源然后找到第一个引导设备,通常为硬盘,然后会查找硬盘的主引导记录(MBR),然后加载到内存中并把控制权交给它,以后的启动过程就由MBR控制. 主引导记录会初始化引导程序(Linux上有两个著名的引导程序,GRUB和LILO,80%的Linux系统在用GRUB引导程

深入理解UIApplication和ios程序启动过程

在深入理解UIApplication前我们先了解ios程序的启动过程: UIApplication类在ios里面为app的管理和协调提供一个集中的点,每一个app有一个UIApplication的实例,当app启动时,系统会调用main函数里面的UIApplicationMain函数,该函数会创建一个UIApplication的实例,设置run loop,启动info.plist里面指定的main.storyboard,加载UIview.

(作业3)Linux内核的启动过程(从start_kernel到init进程启动)

作业题目: 详细分析从start_kernel到init进程启动的过程并结合实验截图撰写一篇署名博客,并在博客文章中注明“真实姓名(与最后申请证书的姓名务必一致) + 原创作品转载请注明出处 + <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 ”,博客内容的具体要求如下: 题目自拟,内容围绕Linux内核的启动过程,即从start_kernel到init进程启动: 博客中需要使用实验截图 博客内容中需要仔细分析