雨和你的故事

前言    ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeepe

1、会话概述在ZooKeeper中，客户端和服务端建立连接后，会话随之建立，生成一个全局唯一的会话ID(Session ID)。服务器和客户端之间维持的是一个长连接，在SESSION_TIMEOUT时间内，服务器会确定客户端是否正常连接(客户端会定时向服务器发送heart_beat，服务器重置下次SESSION_TIMEOUT时间)。因此，在正常情况下，Session一直有效，并且ZK集群

背景与目的Zookeeper开发过程中遇到一些常见问题，为了后续开发不犯同样的错误，总结一下此类问题，并进行分析和解决。适合人员主要适合zookeeper开发、测试及运维相关人员。问题与解决一、 关于zookeeper_init函数的使用问题描述：开发人员在调用zookeeper_init函数时，若返回一个非空句柄zh

[ZooKeeper]连接中断,watch恢复,心跳和客户端超时前一篇文章分析了server端主动超时session的情况，接下来看一下client和server网络暂时中断的情况。1.和server主动关闭连接一样，client抛出EndOfStreamException异常，此时客户端状态还是CONNECTED2.SendThread处理异常，清理连接，将当前所有请求置

转载自：http://blog.youkuaiyun.com/java2000_wl/article/details/8694270获取锁实现思路：1.     首先创建一个作为锁目录(znode)，通常用它来描述锁定的实体，称为:/lock_node2.     希望获得锁的客户端在锁目录下创建znode，作为锁/lock_node的子节点，并且节点类型为有序临时节点(EPHEMER

支付宝系统架构概况典型处理默认资金处理平台财务会计支付清算核算中心交易柔性事务支付宝的开源分布式消息中间件–Metamorphosis(MetaQ)Metamorphosis (MetaQ)

一、设计预期设计预期往往针对系统的应用场景，是系统在不同选择间做balance的重要依据，对于理解GFS在系统设计时为何做出现有的决策至关重要。所以我们应重点关注：失效是常态主要针对大文件读操作：大规模流式读取、小规模随机读取写操作：大规模顺序追加写，写入后很少修改高效明确定义的并行追加写稳定高效地网络带宽二、整体设计1、系统架构GFS主要由以下三个系统模块组成：

京东咚咚架构演进咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。1.0 诞生（2010 - 2011)为了业务的快速上线，1.0 版本的技术架构实现是非常直接且简单粗暴的。 如何简单粗暴法？请看架构图，如下。1.0 的功能十分简单

HDFS 与 GFS 的设计差异后端分布式系列」前面关于 HDFS 的一些文章介绍了它的整体架构和一些关键部件的设计实现要点。我们知道 HDFS 最早是根据 GFS（Google File System）的论文概念模型来设计实现的。然后呢，我就去把 GFS 的原始论文找出来仔细看了遍，GFS 的整体架构图如下：HDFS 参照了它所以大部分架构设计概念是类似的，比

HDFS DataNode 设计实现解析前文分析了 NameNode，本文进一步解析 DataNode 的设计和实现要点。文件存储DataNode 正如其名是负责存储文件数据的节点。HDFS 中文件的存储方式是将文件按块（block）切分，默认一个 block 64MB（该大小可配置）。若文件大小超过一个 block 的容量可能会被切分为多个 block，并存储在不

HDFS NameNode 设计实现解析接前文 分布式存储-HDFS 架构解析，我们总体分析了 HDFS 架构的主要构成组件包括：NameNode、DataNode 和 Client。本文首先进一步解析 HDFS NameNode 的设计和实现要点。元数据持久化NameNode 将所有元信息以特定的数据结构组织存放在内存中，对于 namespace 和 repl

HDFS 架构解析本文以 Hadoop 提供的分布式文件系统（HDFS）为例来进一步展开解析分布式存储服务架构设计的要点。架构目标任何一种软件框架或服务都是为了解决特定问题而产生的。还记得我们在 《分布式存储 - 概述》一文中描述的几个关注方面么？分布式文件系统属于分布式存储中的一种面向文件的数据模型，它需要解决单机文件系统面临的容量扩展和容错问题。所以 H

分布式存储概述分布式存储是相对于单机存储而言，之所以要分布自然是因为互联网时代信息数据大爆炸，单机已经难以满足大型应用的数据存储需求。存储系统的关注点关于存储系统，一般我们关注下面几个方面：数据分布与负载均衡数据存储的可靠性与一致性数据访问性能系统容错能力系统扩展能力在单机存储系统中有一种独立磁盘冗余阵列（RAID，redundant array of

Redis 集群的合纵与连横之前一篇写了关于 Redis 的性能，这篇就写写我认为比性能更重要的扩展性方面的主题。如果再给我一次回到好几年前的机会，对于使用 Redis 我一开始就要好好考虑将来的扩展问题。就像我们做数据库分库分表，一旦决策了分库分表，通常一次就会分到位，比如搞上 8 或 16 个库，每个库再分 256 或 1024 个表。不管将来业务再怎么发展，基本这

数据发布与订阅（配置中心）       发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。      1. 应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一

今天想用一下 zookeeper API，结果编译的时候遇到以下问题。1.问题1问题描述执行完 configure，然后开始编译 make，结果抛出一下错误信息。touch config.h.incd . && /bin/sh ./config.status config.hconfig.status: creating config.hmake  al