ZK

作为服务注册中心，Eureka比Zookeeper好在哪里 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。 1 Zookeeper保证CP 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。 zookeeper原理 zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等） 每启动一个微服务，就会去zk中注册一个临时子节点， 例如：5台订单服务，4台商品服务 （5台订单服务在zk中的订单目录下创建的5个临时节点）

记录Druid单机版安装过程，大体与官网安装过程，加入了个别与官网安装不一致的情况和解决方法 Druid运行依赖zookeeper作为分布式协调服务，下载安装zookeeper wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.11/zookeeper-3.4.11.tar.gz tar -zvf zookeeper-3.4.14.tar.gz ln -s zookeeper-3.4.14 zookeeper 下载Druid安装包： wget http://mirrors.tuna.tsinghua.edu.cn/apache/incubator/druid/0.15.0-incubating/apache-druid-0.15.0-incubating-bin.tar.gz tar -zxf apache-druid-0.15.0-incubating-bin.tar.gz ln -s apache-druid-0.15.0-incubating druid 配置~/.bash_profile 环境变量 vim ~/.bash_profile export JAVA_HOME=/home/homework/jdk export ZK_HOME=/home/homework/zookeeper export

1. Zookeeper 基础 1.1. 部署 先把 ZK 安装起来，后面的很多操作，都是的前提都是由 ZK 的操作环境，先来把 ZK 安装好， 1.1.1. Zookeeper windows 环境 安装 环境要求:必须要 有 jdk环境,本次 讲课使用 jdk1.8 1.安装jdk 2.安装Zookeeper. 在官网 http://zookeeper.apache.org/ 下载 zookeeper.我下载的是zookeeper-3.4.12版本。 解压 zookeeper-3.4.6至D:\machine\zookeeper-3.4.12. 在 D:\machine 新建data及log目录。 3.ZooKeeper的安装模式分为三种，分别为：单机模式（stand-alone）、集群模式和集群伪分布模式。ZooKeeper 单机模式的安装相对比较简单，如果第一次接触ZooKeeper的话，建议安装ZooKeeper单机模式或者集群伪分布模式。 安装单击模式。 至 D:\machine\zookeeper-3.4.12\conf 复制 zoo_sample.cfg 并粘贴到当前目录下，命名zoo.cfg. 1.1.2. Zookeeper 集群配置 1. 安装 jdk 运行 jdk 环境 上传 jdk1.8 安装包 2. 安装 jdk1.8 环境变量 vi /etc

Watcher 在ZooKeeper中，接口类Watcher用于表示一个标准的事件处理器，其定义了事件通知相关的逻辑，包含KeeperState和EventType两个枚举类，分别代表了通知状态和事件类型，同时定义了事件的回调方法：process（WatchedEvent event）。 7.1什么是Watcher接口 同一个事件类型在不同的通知状态中代表的含义有所不同，表7-3列举了常见的通知状态和事件类型。 表7-3 Watcher通知状态与事件类型一览 KeeperState EventType 触发条件 说明 None （-1） 客户端与服务端成功建立连接 SyncConnected （0） NodeCreated （1） Watcher监听的对应数据节点被创建 NodeDeleted （2） Watcher监听的对应数据节点被删除 此时客户端和服务器处于连接状态 NodeDataChanged （3） Watcher监听的对应数据节点的数据内容发生变更 NodeChildChanged （4） Wather监听的对应数据节点的子节点列表发生变更 Disconnected （0） None （-1） 客户端与ZooKeeper服务器断开连接 此时客户端和服务器处于断开连接状态 Expired （-112） Node （-1） 会话超时 此时客户端会话失效

在 ZooKeeper中，接口类Watcher用于表示一个标准的事件处理器，其定义了事件通知相关的逻辑，包含KeeperState和EventType两个枚举类，分别代表了通知状态和事件类型，同时定义了事件的回调方法：process（WatchedEvent event）。 一,什么 是 Watcher 接口 同一个事件类型在不同的通知状态中代表的含义有所不同，表 7-3列举了常见的通知状态和事件类型。 表 7-3 Watcher通知状态与事件类型一览 KeeperState EventType 触发条件 说明 None （-1） 客户端与服务端成功建立连接 SyncConnected （0） NodeCreated （1） Watcher监听的对应数据节点被创建 NodeDeleted （2） Watcher监听的对应数据节点被删除 此时客户端和服务器处于连接状态 NodeDataChanged （3） Watcher监听的对应数据节点的数据内容发生变更 NodeChildChanged （4） Wather监听的对应数据节点的子节点列表发生变更 Disconnected （0） None （-1） 客户端与ZooKeeper服务器断开连接 此时客户端和服务器处于断开连接状态 Expired （-112） Node （-1） 会话超时 此时客户端会话失效

花擦节 闪电购拼团狂欢节 微信中打开：http://www.52shangou.com/buyer/pintuan/index.html Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑们 2015-07-06 黄东旭 高可用架构 此文根据【QCON高可用架构群】分享内容，由群内【编辑组】志愿整理，转发请注明出处。 黄东旭，Ping CAP CTO，开源项目Codis的co-author。之前在豌豆荚从事infrastructure相关的工作，现在在创业公司PingCAP，方向依然是分布式存储领域(NewSQL)。 本次分享的内容主要包括五个大部分： Redis、RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节。   Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。 一、 Redis，RedisCluster和Codis    Redis ：想必大家的架构中，Redis已经是一个必不可少的部件

1.锁 前提：zk中有有序节点，临时节点在用户断开连接后，会自动失效，并且客户端可以watch机制，对一个节点目录进行操作的监视，一旦改目录有变化会通知客户端， 排他锁：只有一个客户端能够获得锁 获取锁：客户端通过create()在/exclusive/下创建lock临时节点/exclusive/lock节点，对于同一个节点，zk保证只有一个用户会创建成功，即得到了锁。其他未得到锁的客户端，watch 节点/exclusive 释放锁：持有锁的客户端主动释放锁，其他等待锁的客户端会收到节点的变化，重新开始获取锁 共享锁：类似读写锁 获取锁： 在需要获取共享锁的时候，客户端会在/shared_lock目录下创建有序临时节点(hostname-请求类型-序号)。例如如果是读请求，会创建192.168.0.1-R-001的节点。如果是写请求，会创建192.168.0.1-W-002的节点。 是否获取到锁的判断： 1. 创建完节点后，获取/shared_lock节点下的所有节点，并对该节点注册子节点变更的watcher监听 确定自己的节点序号在所有子节点中的顺序 对于读请求：如果没有比自己序号小的子节点，或者所有比自己序号小的子节点都是读请求，那么表明自己已经获取到了共享锁 如果比自己序号小的子节点中有写请求，那么就需要进入等待 对于写请求： 如果自己不是序号最小的子节点

1、实现锁 ZK的每一个存在一个顺序节点，在你创建顺序节点时，ZK会自动添加一个自增的编号上去，编号最大是INT_MAX（2147483647 ），如果超出就走溢出，变成负数。 每个获取锁的客户端，在父节点下新建一个自己顺序节点，然后再获取父节点的所有孩子节点，并且设置Watch，观看孩子节点的变化，查看当前第一个节点是否是自己（根据ZK添加的自增编号从小到大排序）。 1、如果是自己即获取到锁，执行业务，然后释放锁。 2、如果不是自己，即未获取到锁，进行thread.wait()，或者再去获取都行。如果wait()，必须在获取孩子节点时设置watch，并且得到孩子节点变化进行notify()。 2、实现Barrier Barrier含义是等待内部事件，然后同时开始，比如等有5人后就开始干活。 实现过程： 1、参与Barrier的选定一个父节点，然后在父节点上设置child类型watch（观察子节点的变化）。 2、在进入barrier的函数里面，设置自己的子节点，获取当前父节点的孩子节点个数，如果等于Barrier size，那就是人到齐了，进行业务处理，业务处理完后，把子节点delete掉。 3、如果不够，则进入thread.wait()。 4、在zk的事件回调函数，调用thread.notify()函数，注意，需要判断EventType。 异常情况处理。 客户端连接中断

为什么需要Zookeeper Zookeeper是一个典型的分布式数据一致性的解决方案， 分布式应用程序可以基于它实现诸如 数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列 等功能。 在解决分布式数据一致性上，Zookeeper已经成为了目前唯一一个比较成熟的方案。 Zookeeper致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力的分布式协调服务。 设计目标 简单的数据结构 冗余，可以构建集群 有序访问 高性能 系统角色 Zookeeper没有沿用传统的Master/Slave模式，使用了Leader、Follwer、Obserfver三种角色。 Zookeeper Atomic Broadcast Zookeeper原子消息广播协议 ZAB的核心定义了那些会改变Zookeeper服务器数据状态的事务请求的处理方式： 所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。 Leader将一个服务请求转换成一个Proposal，然后将这个Proposal分发给集群中其他的Follwer，然后等待Follower处理Proposal的反馈，当超过一定比例的Follower服务器发出正确的反馈后，Leader会发出Commit消息