ES和zookeeper选取帮主之江湖秘闻

ES帮会

某日,ES帮会中决定选取老大统领帮会走向辉煌。
大家七嘴八舌,讨论方案,场面一顿混乱。傻牛站起来大喊一声:谁比俺力气大,谁就当老大。
(ES集群在启动时,选取集群master,按照nodeId进行排序。同时为防止分裂,需一半以上节点同意。)
于是乎,众人决定比拼腕力。经过一番比试,傻牛凭借一身蛮力,决战到最后,并荣获扳手腕大赛。
众人拍手欢呼,单膝下跪,高呼“傻牛帮主牛批,ES帮会千秋万代”。
(当master节点故障时,重复以上选举mater过程。)
次日ES帮会下山打家劫舍,没料到误入陷阱,傻牛被一枪撂倒。ES帮会顿时鸟兽人散。
逃回山寨后,众人决定再选帮主,于是乎,第二届选帮主掰手腕比赛热火朝天的开始了。。。

ZOOKEEPER帮会

五百年后,一群热血青年聚集上海滩,欲成立帮会。时代在进步,相比较ES帮会,ZOOKEEPER帮会的选帮主相对高明。众成员决定在ES帮会选帮主的基础上进行改进,不能每次都用掰手腕来进行决定。遂决定帮主对所有帮会成员进行排序并根据序号颁发令牌。今后若重新选派帮主,根据令牌序号进行排序。
(zookeeper集群在启动时,根据节点id和事务id进行比较。在集群初始化时,事务id都为空,按照节点id进行排序)
众人围坐一团,开始商量第一任帮主人选。许文强一马当先,“帮会刚刚成立,大家的令牌序号都还没有.既然这样,那我们就先比比腕力吧”。经过几轮大战,众人纷纷败给许文强,就这样上海滩,许文强正式成为上海滩ZOOKEEPER帮会第一任帮主。
ZOOKEEPER帮会以运送kafka消息为生,生意蒸蒸日上。终于有一日,一直眼红kafka生意的某军阀施计将许文强抓入大牢。
(当zookeeper集群leader故障时,会重新选取leader。在选举过程中,如果原leader复活,则继续担任leader角色)
帮会不可一日无主,ZOOKEEPER帮会众成员决定择日选举新任帮主,却没料到许文强被军阀的情人冯程程救出。于是昭告江湖,取消择日选取新任帮主,ZOOKEEPER帮会誓死追随强哥。
()
作为强哥的兄弟丁力通过偶然的机会认识了冯程程,对她的美貌一见钟情。而冯程程却对许文强一直倾慕,为了得到冯程程,丁力略施小计,毒杀许文强。
ZOOKEEPER帮会众人听到强哥去世的噩耗,痛心不已。但帮会不可一日无主,于是决定择日选取新任帮主。
(当zookeeper集群leader故障时,会重新选取leader。先比较事务id,如果事务id相同,再根据节点id排序)
选取帮主之日,丁力迫不及待,“当初成立帮主之际,定下的帮主规矩是根据令牌序号进行选举,而我自入帮会以来,一直是千年老二,这下强哥不在了,理当我出任帮主”。众人尽管纷纷不服,但低头看着自己腰间令牌的序号,却也无可奈何,只能同意丁力出任帮主之位。于是,丁力走马上任、出任ZOOKEEPER帮会新任帮主。。。

PS

以上故事纯属虚构,同时故事仅仅阐述了ES、zookeeper选举过程中的重要过程。仍有部分细节,无法对应到故事中,需了解更详细的朋友请自行研究。
以上故事仅仅是让各位朋友能够更好的理解ES、zookeeper选举过程。

原文地址:https://www.cnblogs.com/lcamry/p/11773829.html

时间: 2024-11-07 16:23:57

ES和zookeeper选取帮主之江湖秘闻的相关文章

大数据【六】ZooKeeper部署

这是一个分布式服务框架,阿帕奇的一个子项目.关于ZooKeeper我只简单的部署一下,以便后面的HBase. 一  概述 ZooKeeper 分布式服务框架是 Apache Hadoop 的一个子项目,主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管理等. ZooKeeper是以Fast Paxos算法为基础的. ZooKeeper集群的初始化过程:集群中所有机器以投票的方式(少数服从多数)选取某一台机器作为leader(领导者

Eureka与zookeeper

Eureka的优势 1.在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程:客户端请求会自动切换到新的Eureka节点:当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中:而对于它来说,所有要做的无非是同步一些新的服务注册信息而已.所以,再也不用担心有"掉队"的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了.Eureka甚至被设计用来应付范围更广的网络分割故障,并实现"0"

zookeeper + LevelDB + ActiveMQ实现消息队列高可用

通过集群实现消息队列高可用. 消息队列在项目中存储订单.邮件通知.数据分发等重要信息,故对消息队列稳定可用性有高要求. 现在通过zookeeper选取activemq leader的形式实现当某个activemq节点出问题时,保证系统的可用性. zookeeper做为服务选取器来选择activemq作为master. 开发环境将zoopkeeper zoo_sample.cfg拷贝并修改文件名称为zoo.cfg. activemq 配置禁用kahadb启用LevelDB 其中 zkAddress

eureka和ZooKeeper的区别

背景 在这边文章 中,我们将用我们在实践中遇到的问题来说明,为什么使用ZooKeeper做Service发现服务是个错误. 服务部署环境 让我们从头开始梳理.我们在部署服务的时候,应该首先考虑服务部署的平台(平台环境),然后才能考虑平台上跑的软件 系统或者如何在选定的平台上自己构建一套系统.例如,对于云部署平台来说,平台在硬件层面的伸缩(注:作者应该指的是系统的冗余性设计,即系统遇到单点失 效问题,能够快速切换到其他节点完成任务)与如何应对网络故障是首先要考虑的.当你的服务运行在大量服务器构建的

BASM遵循的规则

任何情况下,在寄存器的使用上,BASM遵循如下的规则:? ASM 语句执行过程中,必须保存EDI.ESI.ESP.EBP.EBX 的值(5个寄存器,意思是可以用,但最后得恢复成原模原样).? ASM 语句可以任意使用EAX.ECX.EDX(三个参数寄存器,也许是编译器提前帮我们存放了三个寄存器的值,并给予恢复).? 一个ASM 代码块开始时,EBP 指向当前堆栈,ESP 指向栈顶(这个当然,EBP=Base).? SS 存放堆栈段的段地址:DS 存放数据段的段地址:CS 存放代码段的段地址(不知

13.容错机制

知识点: 容错机制 一.容错机制:master选举,replica容错,数据恢复 假设有9个shard(3个primary+6个replica), 3个node, 此时如果有一个master node宕机,容错机制如下: 就会有一个primary丢失,在短时间内,status 是red,ES会自动选取另一个node成为新的master node. 新产生的master shard 会将丢失的primay shard 的某一个replica shard 提升为primary shard,此时clu

Eureka的优势

http://www.cnblogs.com/zgghb/p/6515062.html Eureka的优势 1.在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程:客户端请求会自动切换到新的Eureka节点:当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中:而对于它来说,所有要做的无非是同步一些新的服务注册信息而已.所以,再也不用担心有“掉队”的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了.Eure

ES(一): 架构及原理

Elasticsearch 是一个兼有搜索引擎和NoSQL数据库功能的开源系统,基于Java/Lucene构建,可以用于全文搜索,结构化搜索以及近实时分析.可以说Lucene是当今最先进,最高效的全功能开源搜索引擎框架. 说明: Lucene:只是一个框架,要充分利用它的功能,需要使用JAVA,并且在程序中集成Lucene,学习成本高,Lucene确实非常复杂. Elasticsearch 是 面向文档型数据库,这意味着它存储的是整个对象或者 文档,它不但会存储它们,还会为他们建立索引,这样你就

ES学习2

1:es中的分页 一般搜索引擎中的分页都不会提供很大的页面查询,因为查询的页码越大,查询效率越低. 例子: 我们就先预想一下我们在搜索一个拥有5个主分片的索引.当我们请求第一页搜索的时 候,每个分片产生自己前十名,然后将它们返回给请求节点,然后这个节点会将50条 结果重新排序以产生最终的前十名. 现在想想一下我们想获得第1,000页,也就是第10,001到第10,010条结果,与之前同理, 每一个分片都会先产生自己的前10,010名,然后请求节点统一处理这50,050条结果 ,然后再丢弃掉其中的