zookeeper安装与介绍

本文深入讲解ZooKeeper的集群搭建步骤、工作原理及Paxos算法的应用,揭示其如何解决分布式系统中的协调问题。

zookeeper:
    集群搭建:1.解压安装包 tar -zxcf zookeeper-3.4.6.tar.gz
              2.配置环境变量 vim /etc/profile
                    export ZOOKEEPER_HOME=/位置信息
              3.配置zookeeper文件信息
                    进入zookeeper中conf目录下,执行命令 cp zoo.sample.cfg  zoo.cfg
                    配置    datadir=/数据目录信息,不要使用home
                            dataLogDir=/日志目录
                            clientPort=2181
                            server.x=nodenamex:2888:3888(x 为 0,1,2,3,...)  服务id
                            2888: leader 和follower的通讯端口
                            
                    在每个节点下进入datadir数据目录 
                        执行 echo x >> myid x对应于server.x
              4.把zookeeper配置信息发送到各节点中 scp -r /位置信息 节点名:/位置信息
    启动集群: 从每个节点中进入/zookeeper的位置目录/bin
                有zkServer.sh 后接start/status/stop 可以启动集群/查看信息/关闭集群
                有zkCli.sh 启动zk客户端命令
                
                
    zookeeper已经解决了单点故障,提供通用的分布式锁服务,用以协调分布式应用,一种协调服务 团结和睦,一致对外 
        zookeeper应用于大数据分布式协调服务的集群:节点与节点之间可能发生的矛盾
        zookeeper也是一个分布式集群,包含一个简单的原语集,分布式应用程序可以基于他实现;也是主从结构,主leader 
        从follower,对hadoop ha zookeeper做了三件事:1.注册 2.监听事件 3.回调函数
            
    对内:leader挂掉之后,按照一种方式找到一个新的leader,一个一个启动的找出半数serverid最大的为主,一起启动的
    serverid最大的为主;zxid事务id大的来同步; 优先权 zsid>sid
        
    对外:client 直接连接了从节点,增删改查可以向任何一个从服务节点发出请求,但从节点不能直接做决定
    执行流程:从节点从client接收到的请求发送到leader中,1.把请求广播出去给从节点,从结点给leader发送确认信息,只要超
    过半数返回确定则执行请求;2.leader广播给所有的从节点该执行结果,确保每个从节点都接收(消息队列一直存在直到所以消
    息都完成)  实现一致性结果 不能实现完全一致性,只能实现最终一致性,尽最大可能实现一致性
    
    特点:最终一致性:为客户端展示同一个视图
          可靠性:如果消息被同一台服务器接受,那么它将被所有服务器接受
          实时性:zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接
          口
          独立性:各个client互不干扰
          原子性:更新只能成功或者失败,没有中间状态
          顺序性:所有server,同一消息发布顺序一致
          
    Server状态: looking  当前服务不知道主是谁
                 leading 当前服务被选举为主节点
                 following 
            主从分工:  leader 负责进行投票的发起和决议,更新系统状态
                        学习者(learner) 包括 follower和观察者 observer,    follower用于接受客户端请求并向客户端返回结构,在选举主过程中参与投票
                        
                        observer
                            可以接受客户端连接,将写请求转发给leader,但observer不参加投票过程,只同步leader状态,
                            observer的目的是为了扩展系统,提高读取速度
    Zookeeper全解析--Paxos作为灵魂
        Paxos描述了这样的一个场景,有一个叫做Paxos的小岛上面住了一批居民,岛上所有事情有一些特殊的人决定,这些人称为
        议员(senator),议员的总数是确定的,不能更改,岛上每次环境事务的变更都需要 通过一个提议,每个提议都有一个编
        号,这个编号是一直增长的,不能倒退,每个提议都需要超过半数人数以上的议员同一才能生效,每个议员只会同意大于当
        前编号的提议,包括已经生效的和未生效的,如果议员收到小于当前编号的提议,他会决绝,并告知对方,你的提议已经有
        人提过了,这里的当前编号是每个议员在自己记事本上记录的编号,整个议会不会保证所有议员记事本上的编号总是总相
        同,现在议会有一个目标:保证所欲议员对提议都能达成一致的看法。
        好,现在议会开始运作,所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议:
        将电费设定为1元/度。他首先看了一下记事本,嗯,当前提议编号是0,那么我的这个提议的编号就是1,于是他给所有议员
        发消息:1号提议,设定电费1元/度。其他议员收到消息以后查了一下记事本,哦,当前提议编号是0,这个提议可接受,于
        是他记录下这个提议并回复:我接受你的1号提议,同时他在记事本上记录:当前提议编号为1。发起提议的议员收到了超过
        半数的回复,立即给所有人发通知:1号提议生效!收到的议员会修改他的记事本,将1好提议由记录改成正式的法令,当有
        人问他电费为多少时,他会查看法令并告诉对方:1元/度。
        假设总共有三个议员S1-S3,S1和S2同时发起了一个提议:1号提议,设定电费。S1想设为1元/度,S2想设为2元/度。结果S3先
        收到了S1的提议,于是他做了和前面同样的操作。紧接着他又收到了S2的提议,结果他一查记事本,咦,这个提议的编号小
        于等于我的当前编号1,于是他拒绝了这个提议:对不起,这个提议先前提过了。于是S2的提议被拒绝,S1正式发布了提议:
        1号提议生效。S2向S1或者S3打听并更新了1号法令的内容,然后他可以选择继续发起2号提议。
    
        现在让我们来对号入座,看看在ZKServer里面Paxos是如何得以贯彻实施的。
        小岛(Island)——ZKServerCluster
        议员(Senator)——ZKServer
        提议(Proposal)——ZNodeChange(Create/Delete/SetData…)
        提议编号(PID)——Zxid(ZooKeeperTransactionId)
        正式法令——所有ZNode及其数据:
        貌似关键的概念都能一一对应上,但是等一下,Paxos岛上的议员应该是人人平等的吧,而ZKServer好像有一个Leader的概
        念。没错,其实Leader的概念也应该属于Paxos范畴的。如果议员人人平等,在某种情况下会由于提议的冲突而产生一个“活
        锁”(所谓活锁我的理解是大家都没有死,都在动,但是一直解决不了冲突问题)。Paxos的作者Lamport在他的文章”ThePar
        t-TimeParliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统,只有总统有权发出提议,如果议员
        有自己的提议,必须发给总统并由总统来提出。好,我们又多了一个角色:总统。
        总统——ZKServerLeader
        又一个问题产生了,总统怎么选出来的?

        现在我们假设总统已经选好了,下面看看ZKServer是怎么实施的。
        情况一:
        平民甲(Client)到某个议员(ZKServer)那里询问(Get)某条法令的情况(ZNode的数据),议员毫不犹豫的拿出他的记事本(loc
        alstorage),查阅法令并告诉他结果,同时声明:我的数据不一定是最新的。你想要最新的数据?没问题,等着,等我找总
        统Sync一下再告诉你。
        
        情况二:
        平民乙(Client)到某个议员(ZKServer)那里要求政府归还欠他的一万元钱,议员让他在办公室等着,自己将问题反映给了总
        统,总统询问所有议员的意见,多数议员表示欠贫民的钱一定要还,于是总统发表声明,从国库中拿出一万元还债,国库总
        资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。
        情况三:
        总统突然挂了,议员接二连三的发现联系不上总统,于是各自发表声明,推选新的总统,总统大选期间政府停业,拒绝屁民
        的请求。
        
        

内容概要:本文介绍了一项创新性未发表的研究,即利用多元宇宙优化算法(Multiverse Optimizer, MVO)对分时电价下的需求响应综合能源系统调度问题进行建模求解,旨在实现能源系统的经济性、高效性可持续性运行。该研究构建了包含多种能源设备(如光伏、风机、燃气轮机、储能系统等)及可调节负荷的综合能源系统模型,充分考虑了用户侧的需求响应行为在分时电价机制下的响应特性,通过MVO算法对系统运行成本、能源利用率、碳排放等多目标进行协同优化,实现了日前调度计划的智能决策。研究还提供了完整的MATLAB代码实现,便于研究人员复现实验、验证算法性能,并为进一步研究提供可靠的仿真基础。; 适合人群:具备一定电力系统、优化算法及MATLAB编程基础的科研人员、研究生以及从事能源互联网、综合能源系统规划运行的技术工程师。; 使用场景及目标:① 学习并掌握多元宇宙优化算法在复杂能源系统调度中的具体应用方法;② 研究分时电价机制如何通过需求响应引导用户参电网互动,实现削峰填谷;③ 实现综合能源系统(IES)中冷、热、电、气等多种能源的协同优化调度,以降低运行成本、提高新能源消纳能力和系统可靠性;④ 为相关领域的学术研究提供可复现的代码实例和仿真平台。; 阅读建议:此资源以MATLAB代码为核心载体,深入剖析了算法应用系统建模的全过程。建议读者在学习时,不仅应关注代码的实现细节,更要理解其背后的数学模型、优化目标设定和约束条件的物理意义。建议结合文档中的模型描述,逐步调试代码,观察不同参数和场景下的优化结果,从而深刻掌握综合能源系统优化调度的设计思想关键技术。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值