zookeeper
本文主要是来浅谈一下zookeeper，如果有什么不对的话，欢迎指教~
基本介绍
•Zookeeper由雅虎研究院开发，是Google Chubby的开源实现，后来托管到Apache，于2010年11月正式成为Apache的顶级项目。
•Zookeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
•分布式应用程序可以基于Zookeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。
•ZooKeeper本质上是一个分布式的小文件存储系统。原本是Apache Hadoop的一个组件，现在被拆分为一个Hadoop的独立子项目，在Hbase（Hadoop的另外一个被拆分出来的子项目，用于分布式环境下的超大数据量的DBMS）中也用到了ZooKeeper集群。
应用案例
•RPC服务框架： Dubbo
•Mysql Binlog的订阅与消费： Cannal
•分布式数据库同步系统： Otter
•分布式搜索平台： 终搜
•实时计算引擎： Jstorm
•Hbase
•Hadoop
•kafka
应用场景
配置中心：
•应用中可以将一些配置信息放到 ZK 上进行集中管理，比如一些服务器的IP地址
•开源的dubbo就是将服务信息注册到ZK上
•一般存储的数量不能过大
命名服务：
•名称服务是将一个名称映射到与该名称有关联的一些信息的服务。电话目录是将人的名字映射到其电话号码的一个名称服务。同样，DNS 服务也是一个名称服务，它将一个域名映射到一个 IP 地址。在分布式系统中，您可能想跟踪哪些服务器或服务在运行，并通过名称查看其状态。Zookeeper 暴露了一个简单的接口来完成此工作。也可以将名称服务扩展到组成员服务，这样就可以获得与正在查找其名称的实体有关联的组的信息。
分布式协调通知：
•zookeeper中特有的watcher注册于异步通知机制，能够很好的实现分布式环境下不同系统之间的通知于协调，实现对数据变更的实时处理。使用方法通常是不同系统对ZK上同一个znode进行注册，监听znode的变化，其中一个系统修改了znode，那么另一个系统就能够收到通知，并作出相应的处理
分布式锁：
•分布式锁，这个主要得益于 Zookeeper 为我们保证了数据的强一致性，通常的做法是把 zk 上的一个 znode 看作是一把锁，通过 create znode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁
集群管理：
•集群管理，比如要监控集群机器，一般的做法是会有个监控系统，定时去检测机器是否存活，通常的做法就是通过ping定时检测每个机器。我们可以通过zookeeper的Ephemeral类型节点，再往注册watcher事件，一旦客户端与服务器会话结束与过期，那么该节点就会消失，并且将事件发给订阅者，这样监控系统就可以知道哪台机器下线了
Master选举：
•我们可以通过Zookeeper的EPHEMERAL_SEQUENTIAL的特性做一个简单的选举功能
基本原理
•Zookeeper 有一个类似于文件系统的数据模型，由 znodes 组成。可以将 znodes（Zookeeper 数据节点）视为类似 UNIX 的传统系统中的文件，但它们可以有子节点。另一种方式是将它们视为目录，它们可以有与其相关的数据。每个这些目录都被称为一个 znode
•该图表示了两个城市中的运动队的层次结构
znode：
•节点类型：ZK中有几种节点类型，节点类型在节点创建的时候就被确定且不可改变
•临时节点（EPHEMERAL）：临时创建的，会话结束节点自动被删除，也可以手动删除，临时节点不能拥有子节点
•临时顺序节点（EPHEMERAL_SEQUENTIAL）：具有临时节点特征，但是它会有序列号，分布式锁中会用到该类型节点
znode基本命令：
•1、ls /
•2、create [-e][-s] /weicheng aaa
•3、get /weicheng
•4、set /weicheng bbb
•5、delete /weicheng
•6、rmr /weicheng
•持久节点（PERSISTENT）：创建后永久存在，除非主动删除。
•持久顺序节点（PERSISTENT_SEQUENTIAL）：该节点创建后持久存在，相对于持久节点它会在节点名称后面自动增加一个10位数字的序列号，这个计数对于此节点的父节点是唯一，如果这个序列号大于2^32-1就会溢出。
Watcher
Watcher 的理念是启动一个客户端去接收从 Zookeeper 服务端发过来的消息并且同步地处理这些信息。Zookeeper 的 Java API 提供了公共接口 Watcher，具体操作类通过实现这个接口相关的方法来实现从所连接的 Zookeeper 服务端接收数据。如果要处理这个消息，需要为客户端注册一个 callback（回调）对象。
public interface Watcher {
abstract public void process(WatchedEvent event);
}
角色介绍：
•Leader: 负责进行投票的发起和决议，更新系统状态
•Follower: 用于接受客户端请求并想客户端返回结果
•Observer: follower用于接受客户端请求并想客户端返回结果
ZAB：
•Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做ZAB协议
•ZAB协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态
•为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
该协议需要做到以下几点：
（1）集群在半数以下节点宕机的情况下，能正常对外提供服务
（2）客户端的写请求全部转交给leader来处理，leader需确保写变更能实时同步给所有follower及observer
（3） leader宕机或整个集群重启时，需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交，确保丢弃那些只在leader服务器上被提出的事务，并保证集群能快速恢复到故障前的状态
（4）任何时候都需要保证只有一个主进程负责进行事务操作，而如果主进程崩溃了，就需要迅速选举出一个新的主进程
zookeeper选举 :
leader选举是Zookeeper中最重要的技术之一，也是保证分布式数据一致性的关键所在。当集群中的一台服务器处于如下两种情况之一时，就会进入leader选举阶段——服务器初始化启动、服务器运行期间无法与leader保持连接。
选举阶段，集群间互传的消息称为投票，投票Vote主要包括二个维度的信息：SID、ZXID
•SID 为每个服务器的ID，集群中的每个zookeeper节点启动前就要配置好这个全局唯一的ID。
•ZXID 为服务器的事务ID ，该值是从机器DataTree内存中取的，即事务已经在机器上被commit过了。
节点进入选举阶段后的大体执行逻辑如下：
（1）设置状态为LOOKING，初始化内部投票Vote (sid,zxid) 数据至内存，并将其广播到集群其它节点。节点首次投票都是选举自己作为leader，将自身的服务ID、处理的最近一个事务请求的ZXID（ZXID是从内存数据库里取的，即该节点最近一个完成commit的事务id）及当前状态广播出去。然后进入循环等待及处理其它节点的投票信息的流程中。
（2）循环等待流程中，节点每收到一个外部的Vote信息，都需要将其与自己内存Vote数据进行PK，规则为取ZXID大的，若ZXID相等，则取ID大的那个投票。若外部投票胜选，节点需要将该选票覆盖之前的内存Vote数据，并再次广播出去；同时还要统计是否有过半的赞同者与新的内存投票数据一致，无则继续循环等待新的投票，有则需要判断leader是否在赞同者之中，在则退出循环，选举结束，根据选举结果及各自角色切换状态，leader切换成LEADING、follower切换到FOLLOWING、observer切换到OBSERVING状态。
好了今天就先分享到这里先~欢迎大家评论~