目录
Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。
Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。
每个sever首先给自己投票，然后用自己的选票和其他sever选票对比，权重大的胜出，使用权重较大的更新自身选票箱。具体选举过程如下：
1.每个sever启动以后都询问其他的sever他要投票给谁。对于其他server的询问，sever每次根据自己的状态都回复自己推荐的leader的ID和上一次处理事务的zxid（系统启动时每个sever都会推荐自己）
2.收到所有Sever回复后，就计算出zxid最大的那个sever,并将这个Sever相关信息设置成下一次要投票的Sever。
3.计算这过程中获得票数最多的Sever为获胜者，如果获胜者的票数超过半数，则改为sever被选为Leader。否则，继续这个过程，直到leader被选举出来。
4.Leader就会开始等待sever连接。
5.Follower连接Leader，将最大的zxid发送给leader.
6.Leader根据follower的zxid确定同步点，至此选举阶段完成。
7.选举阶段完成Leader同步后通知follower已经成为uptodate状态。
8.Follower收到update消息后，又可以重新接收client的请求进行服务了，目前有5台服务器，每台服务器均没有数据，他们的编号分别是1,2,3,4,5按编号依次启动，他们的选举过程如下：
9.服务器1启动，给自己投票，然后发投票信息，由于其他机器还没有启动所以他收不到反馈信息，服务器1的状态一直属于Looking。
10.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是Looking。
11.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
12.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
13.服务器5启动，后面的逻辑同服务器4成为小弟。
1.Zookeeper的核心是原子广播，这个机制保证了各个sever之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，他们分别是回复模式和广播模式。
2.当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数sever的完成了和leader的状态同步以后，恢复模式就结束了。
3.状态同步保证了Leader和Sever具有相同的系统状态。
4.一旦Leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Sever假如zookeeper服务中，他会在回复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，他也参与消息广播。zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者Leader失去了大部分的follower支持。
5.广播模式需要保证proposal被顺序处理，因此zk采用了递增的事务id号（zxid)来保证。所有的提议（proposal）都在被提出的时候加上了zxid。
6.实现中zxid是一个64位的数字，他高32位是epoch用来标识Leader关系是否改变，每次一个Leader被选出来，他都会有一个新的epocha。低32位是个递增计数。
7.当leader崩溃或者Leader失去大多数的follower，这时候zk会进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的sever都恢复到一个正确的状态。
1.PERSISENT：持久的节点。
2.EPHEMERAL：暂时的节点。
3.PERSISTENT? ?SEQUENTIAL：持久化顺序编号目录节点。
4.EPHEMERAL? SEQUENTIAL：暂时化顺序编号目录节点。
Dubbox和Dubbo本质上没有区别，名字的含义扩展了Dubbo而已，以下Dubbox是扩展出来的功能：
1.支持REST风格远程调用（HTTP+JSON/XML)
2.支持基于Kryo和FST的Java高效序列化实现
3.支持基于Jackson的JSON序列化
4.支持基于嵌入式Tomcat的HTTP? remoting体系
5.升级Spring至3.x；
6.升级Zookeeper客户端
7.支持完全基于Java代码的Dubbo配置