zookeeper服务器挂掉，客户端重连的次数能设置吗？
[问题点数：30分，结帖人lwjpker]
zookeeper服务器挂掉，客户端重连的次数能设置吗？
[问题点数：30分，结帖人lwjpker]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
匿名用户不能发表回复！|dubbo使用的zookeeper注册中心客户端太多导致连不上解决办法|linux的arp限制
<span type="1" blog_id="2059015" userid='
分享到朋友圈
关注作者，不错过每一篇精彩携程高级构架经理李欣：ZooKeeper在携程的使用及前景
发表于 14:59|
摘要：在9月9日“研发实践”主题论坛中，携程高级构架经理为我们带来了题为《ZoopKeeper在携程的使用及前景》的主题演讲，介绍携程技术研发中心；Zookeeper的介绍以及ZooKeeper在携程的应用和使用场景介绍。
【CSDN现场报道】2012中国软件开发者大会（SDCC）于9月8-9日在国家会议中心召开，本次大会由CSDN、《程序员》杂志、ITEye合办。作为年度最具实战的技术盛会，大会云集了来自国内外一线互联网和企业级软件公司的实战专家，就高可用性系统架构、海量数据挖掘、开放平台服务与架构、智能推荐系统、异构计算等话题和参会者进行了深入分享与探讨。
9日&研发时间&专场邀请到了携程高级构架经理李欣给我们带来题为《ZooKeeper在携程的使用及前景》的主题演讲，介绍携程技术研发中心；Zookeeper的介绍以及ZooKeeper在携程的应用和使用场景介绍。
携程给大家留下的印象是一个互联网公司，最近携程有很大的改变，对技术研发的投入是不断增加。成立三个架构组，包括app、IOS。我们内部也鼓励更多优秀的开源软件，Zookeeper也是一个例子。
首先要介绍Zookeeper的一些基本概念介绍：首先讲一下Zookeeper这个项目，本身是一个Hadoop的资项目。
Zookeeper的架构：所有的server组成一个从Zookeeper的服务，server和server之间的交互是通过协议进行通信，选取出一个leader，负责向follower广播所有变化消息。其实所有的follower都和leader通信，follower接受来自leader的所有变化信息，保存在自己的内存。follower转发来自客户端的写请求给leader。客户端的读请求会在follower端直接服务，无须转发给leader。
ZAB（Zookeeper& Atomic& Broadcast）协议：首先2011年Yahoo公开了Zab协议论文。第二选举了leader，只有leader才能提出决议。这就意味着其实跟消息发送的次序是非常有关系的，所以内部的通信基本上都是通过TPS来做的。第三没有abort的两段式提交。第四是基于状态增量的消息传输。第五是高可用、高性能。
Zookeeper的数据模型类似一个文件系统，它是基于属形结构的命名空间，与文件系统类。每个节点都可以存储数据，也可以有自己的节点。
Zookeeper Session：客户端和server间采用长连接。连接建立后，server产生session ID返还给客户端。客户端定期发送pin包来检查和保持和server的连接。一旦session结束或超时，所有ephemeral而节点会被删除。客户端可根据情况设置合适的session超时时间。
Zookeeper& Watches：Watches是客户端安装在server的事件侦听方法；当侦听的变化发生时，server发消息给客户端进行通知。客户端使用单线程对所有事件按顺序同步回调。每次触发后会被自动删除。如果需要再次侦听事件，必须重新安装Watches。无法保证跟踪到每一个变化，避免安装大量的Watches侦听在同一个节点。Watches的创建和触发规则：所有的API是怎么创建一个Watches，写请求的API，会触发一些事件。举一个例子：当我们调用Watches，我们用一个create，谁创建这个Watches这个节点就会被触发掉。
Observer：不参与选举，永远是follower。Observer数量增加，进一步提升集群的服务能力。不会增加重新选举leader的开销。很好地支持跨数据中心、本地读、异地写的功能。
Zookeeper的一些陷阱：首先客户端事件毁掉实现有阻塞调用；第二是试图跟踪每一个状态变化，只能拿到当前的，在当前状态下注册一个watches，客户端会有需要长时间处理的GC。
Zookeeper.net客户端：我们非常需要一个Zookeeper.net的客户端，现在是官方推荐的，可以支持3.4.3版本，是最新版本。从Java的Zookeeper客户端移植过来。Zookeeper的封装层：为什么需要额外的封装层：.net客户端底层不提供可靠的API支持要解决这个问题是非常困难的。最主要的一些连接问题，包括两种：一个是CONNECTION_loss的处理：底层会挑选下个服务器进行重连，以自动恢复。封装层必须有重试机制，确保在重连后检查状态并正确处理。封装层的恢复策略必须区分幂等调用与非幂等调用。要特别当心创建sequential节点调用。
Session_EXPIRED的处理：向框架报告错误、由框架决定如何恢复所有的ephemeral而节点。
Job调度系统存在单点故障的问题：关键组件只有单实例运行，无HA保障。
Master/Slave的实现：
场景1，首先只在无法做到active-active时的考虑。父节点类型为persistent。子节点类型为ephemeral+sequential。客户端启动时创建子节点。序列号虽料子节点选为Master，其他子节点都是slave，每各slave侦听序列号比它小的子节点中最大的子节点的NodeDeleted事件。一旦这个事件被触发以后，客户端就要重新选择侦听对象，如果侦听对象不存在的话，就没有一个子节点序列号比自己小，他自己最小就会很麻烦，就执行Master相应的逻辑。
场景2：讲一个Forever& Running& Job，调度太频繁，需要把此类Job转变成Forever& Running& Job。Forever& Running& Job要用到Jobworker主管理人员，在worker里面会创建一个子节点，这个子节点会用Jobld命名的ephemeral/non/sequential的Job子节点，如果无法创建该子节点，说明已有同名Job实例在运行，本次实例启动中止。
场景3：Job调度系统继续演化，太多Job需要处理，导致耽搁JobScheduler而成为瓶颈，需要做sharding，多个JobScheduler实例同时运行，则需要HA保护。这就需要我们Hot& Standby的实现：预定X个角色，Y个Hot& Standby，因此一定需要X+Y的客户端。创建X各persistent/eon-seq而节点作为角色节点，其数据进存放某个客户端子节的序列号。客户端启动时，创建ephemeral+sequential子节点，然后检查并获得当前活动的其他客户端的子节点。客户端扫描每个角色节点的数据，如果某个角色节点的数据中存放的序列号已关联到某个活动客户端的子节点，或序列号比自己的大，那么跳过该角色节点。否则，就用自己的序列号更新该角色节点的数据，如果赋值成功，则客户端运行该角色的应用逻辑。如果无法找到任何角色节点进行赋值，则客户端自动成为Hot& Standby，删除其创建的子节点，监控所有其他执行角色任务。
场景4：是分配订单号，要分配全局唯一的连续单调递增序列值。32位序列号产品器实现：为每一个sepwquence对象创建一个persisent节点。条用set/data，把期望的数据版本号设成-1，Zookeeper将不做期望版本号校验，调用总会成功，该节点的数据版本号自动+1。更高位序列号产生器实现：为每一个sepwquence对象创建一个persisent节点，在节点的数据中存放最后分配的序列号，调用get-data。邮电是可以产于32位的序列号，缺电是多步调用，且有竞争可能，如果竞争过多，可考虑使用分布锁。
场景5：网站操作任务许可系统。需求：众多网站操作任务，同时运行可能会相互冲突，不能同时进行。有些也是有依赖关系的，就意味着你对这些操作要进行管理，要进行一些互斥的操作。这时候会用到一些分布式锁的实现。分布式锁也挺简单：每个锁的对象就是persisent节点，客户端在申请锁的时候，就在这个节点下面创建一个ephemeral+sequential子节点，客户端检查该锁对象节点下的所有子节点。如果客户端发现自己的子节点拥有最小的序列号，则说明该客户端拥有了锁。解锁时，拥有锁的客户端只需删除自己的子节点。
场景6：生产配置发布系统，如果采用配置推送方式，步骤太多且容易出错，排碍比较困难，还要向各个进行推送。能控制一个pool内的配置更新速度。分布式配置实现：为每个pool分配结构化的路径，除了app的实例节点外，其余节点均为persisent节点，app实例在相应的pool相应的版本节点下创建ephemeral子节点，并侦听该子节点的NodeDataChanged通知。配置为key/value集合，存放在各个节点的数据中。需要app实例更新配置时，调用set/data以触发app节点NodeDataChanged事件。生产配置发布系统解决方案：我们会通过一个组件同步到Zookeeper里面，watch所有都会跟Zookeeper连接。
更多精彩内容，请关注，。
本文为CSDN原创，未经允许不得转载。如需转载请联系。
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)尊敬的极客用户，您好！
感谢您一直关注并使用极客头条，为了给您带来良好的体验效果及性能，极客头条将于日关闭，您可以在
中继续使用发布文章功能并看到已经发布成功的文章。
主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
CSDN &《程序员》研发主编，投稿&纠错等事宜请致邮
你只管努力，剩下的交给时光！
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：www.xttblog.com。个人QQ群：、
个人大数据技术博客：https://www.iteblog.com}