团队博客:http://rdc.taobao.com/team/jm/archives/tag/zookeeper《ZooKeeper快速搭建》http://nileader.blog.51cto.com/1381108/795230《ZooKeeper Java API 使用样例》http://nileader.blog.51cto.com/1381108/795265《可视化zookeeper
公司之前进行了几次机房容灾演习中,经常是模拟一个机房挂掉的场景,把一个机房的网络切掉,使得这个机房内部网络通信正常,与外部的网络不通。在容灾演习过程中,我们发现ZK的客户端应用中出现大量类似这样的日志: An exception was thrown while closing send thread for ession 0x for server null, unexpected error, closing socket connection and attempting 从这个日志中,红色部分出现的是null。当时看到这个情况,觉得,正常情况正在,这个地方应用出现的是那个被隔离的机房中部署的ZK的机器IP的,但是这里出现的是null,非常困惑。 具体描述也可以在这里查看:https://issues.apache.org/jira/browse/ZOOKEEPER-1480
转载请注明:@ni掌柜 nileader@gmail.com 本文主要是讨论下两个类似产品:ZooKeeper和Diamond在配置管理这个应用场景上的异同点。 Diamond,顾名思义,寄寓了开发人员对产品稳定性的厚望,希望它像钻石一样,提供稳定的配置访问。Diamond是淘宝网Java中间件团队的核心产品之一,服务于集团线上很多核心应用。
ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,也正是基于这样的特性,使得ZooKeeper解决很多分布式问题。网上对ZK的应用场景也有不少介绍,本文将结合作者身边的项目例子,系统地对ZK的应用场景进行一个分门归类的介绍。 值得注意的是,ZK并非天生就是为这些应用场景设计的,都是后来众多开发者根据其框架的特性,利用其提供的一系列API接口(或者称为原语集),摸索出来的典型使用方法。因此,也非常欢迎读者分享你在ZK使用上的奇技淫巧。
正常工作比较大的影响: 1. 用于zookeeper写日志的目录要有足够大小,并且强烈建议在单独的磁盘(挂载点)上,这是影响ZK性能最大因素之一。 2. 连接数。 3. 注册的Watcher数。 4. ZNode是否可读,可写。 5. ZK事件通知的延时是否过大。 围绕以上几点展开,完成了taokeeper一期的开发,目前主要完成以下方面的监控:(项目地址:https://github.com/taobao/taokeeper) 1. CPU/MEM/LOAD的监控 2. ZK日志目录所在磁盘剩余空间监控 3. 单机连接数的峰值报警 4. 单机 Watcher数的峰值报警 5. 节点自检:是指对集群中每个IP所在ZK节点上的PATH:
本文以ZooKeeper3.4.3版本的官方指南为基础:http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html,补充一些作者运维实践中的要点,围绕ZK的部署和运维两个方面讲一些管理员需要知道的东西。本文并非一个ZK搭建的快速入门,关于这方面,可以查看《ZooKeeper快速搭建》。
在ZooKeeper的运维过程中,我们经常会碰到这样的问题,就是快照数据文件越来越大,但是ZooKeeper上的数据节点数量并没有相应的增加。 这说明什么问题:一定是有客户端在将ZooKeeper当数据库使用了。长此以往,必然会引起ZooKeeper内存数据过大而影响性能及集群间的数据同步。
无论使用哪种Leader选举方法,一个机器要想成为Leader,都必须具备以下两点: - Leader一定是所有机器中zxid最新的。 - 集群中必须大于等于quorum台机器同意。 当一个Leader被选出后,那么其余的机器都会和这个机器来连接上,并开始同步状态。如果一个Follower落后的状态过多的话,那么就会将整个snapshot同步给他。 新的Leader会根据当前最大的zxid来确定下次开始的zxid。当所有的Follower已经和Leader保持同步之后,Leader会向所有的Follower发出“NEW_LEADER”的提议,一旦过半的机器接受了这个提议, 也就是说这个提议能够被提交,接下去Leader才被真正激活,并开始对外服务:开始接收新的请求并处理。 这个算法听起来有点复杂,但实际上,只要遵守一下4点就可以选出Leader - Follower在和Leader保持同步之后,就会对“NEW_LEADER”提议响应ACK。 - A follower will only ACK a NEW_LEADER proposal with a given zxid fro
【ZooKeeper Notes 23】Leader选举-来自邮件列表
为了提升系统的性能,进一步提高系统的吞吐能力,最近公司很多系统都在进行异步化改造。在异步化改造的过程中,肯定会比以前碰到更多的多线程问题,上周就碰到ZooKeeper客户端异步化过程中的一个死锁问题,这里说明下。
转载请注明 @ni掌柜 nileader@gmail.com 本文主要讲述在使用ZooKeeper进行分布式锁的实现过程中,如何有效的避免“羊群效应( herd effect)”的出现。 一般的分布式锁实现 这里简单的讲下一般的分布式锁如何实现。具体的代码实现可以在这里看到: https://svn.a
转载请注明:@ni掌柜 nileader@gmail.com 1.Watches通知是一次性的,必须重复注册. 2.同一个ZK客户端,反复对同一个ZK节点(znode)注册相同的watcher,是无效的,最终只会有一个生效。 3.发生CONNECTIONLOSS之后,只要在session_timeout之内再次连接上(即不发生SESSIONEXPIRED),那么这个连接注册的wa
转载请注明:@ni掌柜 本文重点围绕ZooKeeper的Watcher,介绍通知的状态类型和事件类型,以及这些事件通知的触发条件。 1、浅谈Watcher接口 在ZooKeeper中,接口类Watcher定义了事件通知相关的逻辑,包含了KeeperState和EventType两个枚举类,分别代表通知状态和事件类型。还有一个比较重要的接口方法:
转载请注明:@ni掌柜 nileader@gmail.com 本文主要讲述ZooKeeper的数据模型,包括ZooKeeper的数据视图,节点的层次结构以及节点类型等基本属性。Zookeeper的视图结构类似标准的Unix文件系统,但是没有引入文件系统相关概念:目录和文件,而是使用了自己特有的节点(node)概念,称为znode。Znode是ZooKeeper中数据的最小单元,每个znode上都
在ZooKeeper中,客户端和服务端建立连接后,会话随之建立,生成一个全局唯一的会话ID(Session ID)。服务器和客户端之间维持的是一个长连接,在SESSION_TIMEOUT时间内,服务器会确定客户端是否正常连接(客户端会定时向服务器发送heart_beat,服务器重置下次SESSION_TIMEOUT时间)。因此,在正常情况下,Session一直有效,并且ZK集群所有机器上都保存这个Session信息。在出现网络或其它问题情况下(例如客户端所连接的那台ZK机器挂了,或是其它原因的网络闪断),客户端与当前连接的那台服务器之间连接断了,这个时候客户端会主动在地址列表(实例化ZK对象的时候传入构造方法的那个参数connectString)中选择新的地址进行连接。
查看PDF版本 转载请用注明:@ni掌柜nileader@gmail.com 在之前一个文章《ZooKeeper Java API 使用样例》中提到,客户端使用ZooKeeper的时候,首先会建立与ZooKeeper的连接,方法是通过调用下面这个构造方法来实现的。 public ZooKeeper(String connectString, 
在使用zookeeper过程中,我们知道,会有dataDir和dataLogDir两个目录,分别用于snapshot和事务日志的输出(默认情况下只有dataDir目录,snapshot和事务日志都保存在这个目录中,关于这两个目录的详细说明,请看《ZooKeeper管理员指南》)。 正常运行过程中,ZK会不断地把快照数据和事务日志输出到这两个目录,并且如果没有人为操作的话,ZK自己是不会清理这些文件的,需要管理员来清理,这里介绍4种清理日志的方法。在这4种方法中,推荐使用第一种方法,对于运维人员来说,将日志清理工作独立出来,便于统一管理也更可控。毕竟zk自带的一些工具并不怎么给力:
如果客户端设置了权限,那么其它人如果没有授权,就无法对这个节点进行操作。但是对于管理员来说,有没有一种方法,可以对任意节点进行操作呢,答案是有的~
zookeeper客户端对server的操作都是不可回退的,意思是说,zk的客户端每次和server进行通信的时候,会记住server上最新的zxid。如果某个时刻,客户端和server断开了连接,那么等到下次重新连接到集群中的机器上时,会检查当前连接上的那个server是否和client有相同的zxid,或者已经是更新的zxid了。一旦客户端发现server的zxid比自己小,那么客户端会断开和这个server的连接,并且重新连接集群中的其它server~ 1. zxid是检验的标准 2. 这里是客户端主动断开连接,尝试连接其它server的~
1. 分配不同的myid。 2. 不同实例,clientPort一定要不同。 3. 使用不同的zoo.cfg文件,并且dataDir和dataLogDir目录要不同。
前面提到,在zookeeper server的配置文件zoo.cfg中可以通过dataLogDir来配置zookeeper的事务日志的输出目录,这个事务日志类似于下面这样的文件: 这个文件是一个二进制文件, 一般不能够直接识别, 那么是否有方法可以把这些事务日志转换成正常日志文件呢, 答案是肯定的~
1. 客户端对ServerList的轮询机制是什么 随机,客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中,将所有Server保存在一个List中,然后随机打散,形成一个环。之后从0号位开始一个一个使用。 两个注意点:1. Se
原文:http://rdc.taobao.com/team/jm/archives/1334 (所有要下载的文件都在这里:https://issues.apache.org/jira/browse/ZOOKEEPER-1320) ZooKeeper功能定位专一,这“导致”了他并不支持一些&
PDF下载 目前在公司内部使用ZooKeeper的地方越来越多,应用大多喜欢自己部署一套ZK集群来使用。考虑到ZK的高可用,并且一套ZK集群至少3台机器, 那么每个应用,尤其是一些非核心应用都自己去部署一套的话,对资源利用率很低。另外,随着ZK容灾的提出,单套ZK集群使用的机器量会更大,运维人员开始 对这个情况担忧,强烈希望能够合并ZK集群
上周听了淘宝网技术专家蒋江伟的一个分享《淘宝前台系统优化实践-吞吐量优化》 , 对其中“编写GC友好的代码”一节颇有兴趣,并存在疑问,回去后反复试验,从网上找资料,在蒋江伟的帮助下,算是得出了自己的结论。 首先,根据分享内容,结合
查看PDF版本 转载请注明:@ni掌柜 nileader@gmail.com ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务框架,包含一组简单的原语集合。通过这些原语言的组合使用,能够帮助我们解决更高层次的分布式问题,关于ZooKeeper的典型使用场景,请查看这个文章《ZooKeeper典型使用场景一览》 本文主要针对ZooKeeper提供的Java API,通过实际代
转载请用注明:@ni掌柜 nileader@gmail.com 下载PDF版本 本文是ZooKeeper的快速搭建,旨在帮助大家以最快的速度完成一个ZK集群的搭建,以便开展其它工作。本方不包含多余说明及任何调优方面的高级配置。如果要进行更深一层次的配置,请移步《ZooKeeper管理员指南&mdash
h y
ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,也正是基于这样的特性,使得zookeeper能够应用于很多场景。网上对zk的使用场景也有不少介绍,本文将结合作者身边的项目例子,系统的对zk的使用场景进行归类介绍。 值得注意的是,zk并不是生来就为这些场景设计,都是后来众多开发者根据框架的特性,摸索出来的典型使用方法
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号