转载请注明：@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并不是生来就为这些场景设计，都是后来众多开发者根据框架的特性，摸索出来的典型使用方法
最近公司在进行自主提名的晋升，但是规定了应届生的话必须要在7月1日之前入职的才有资格。哎。悲剧?了。 ? 转发至微博 转发至微博
上周公司团队去了舟山的朱家尖游玩了. 先去了沙滩, 整个下午都在沙滩和海水中度过,不错. 第二天去爬山, 划船出海, 去水上乐园玩. 虽然这个水上乐园不是一般的坑爹. 第三天下午回来了. 吃好好多海鲜, 回来之后, 很多人都肚子拉的欲仙欲死...
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
