001-zookeeper 简介-paxos算法，zk简介，特点

一、概述

　　大数据体系概述

　　

1.1、什么是zookeeper

　　是Google的Chubby一个开源的实现，是Hadoop的分布式协调服务

　　它包含一个简单的原语集，分布式应用程序可以基于他实现同步服务，配置维护和命名服务等。

　　是保证分布式数据一致性的一种手段　　　　

　　

　　Zookeeper默认采用FastLeaderElection算法,然而FastLeaderElection对于Zookeeper来讲只是相当于paxos中的leader选举。 
  下面我们用最简单的方式加以描述并建立起Paxos和ZKServer的对应关系。

1.2、paxos算法理解

　　Paxos描述了这样一个场景:

  1、有一个叫做Paxos的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做*(Senator)。
  2、*的总数(SenatorCount)是确定的，不能更改。
  3、岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。
  4、每个提议都需要超过半数((SenatorCount)/2+1)的*同意才能生效。
  5、每个*只会同意大于当前编号的提议，包括已生效的和未生效的。
  6、如果*收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个*在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有*记事本上的编号总是相同的。

现在议会有一个目标：保证所有的*对于提议都能达成一致的看法。

  好，现在议会开始运作，所有*一开始记事本上面记录的编号都是0。
  有一个*发了一个提议：
  将电费设定为1元/度。他首先看了一下记事本，嗯，当前提议编号是0，那么我的这个提议的编号就是1，于是他给所有*发消息：1号提议，设定电费1元/度。其他*收到消息以后查了一下记事本，哦，当前提议编号是0，这个提议可接受，于是他记录下这个提议并回复：我接受你的1号提议，同时他在记事本上记录：当前提议编号为1。发起提议的*收到了超过半数的回复，立即给所有人发通知：1号提议生效！收到的*会修改他的记事本，将1好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1元/度。

现在看冲突的解决：

  假设总共有三个*S1-S3，S1和S2同时发起了一个提议:1号提议，设定电费。S1想设为1元/度,S2想设为2元/度。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是S2的提议被拒绝，S1正式发布了提议:1号提议生效。S2向S1或者S3打听并更新了1号法令的内容，然后他可以选择继续发起2号提议。

  好，我觉得Paxos的精华就这么多内容。现在让我们来对号入座，看看在ZKServer里面Paxos是如何得以贯彻实施的。
  小岛(Island)——ZKServerCluster
  *(Senator)——ZKServer
  提议(Proposal)——ZNodeChange(Create/Delete/SetData…)
  提议编号(PID)——Zxid(ZooKeeperTransactionId)

正式法令——所有ZNode及其数据：
  貌似关键的概念都能一一对应上，但是等一下，Paxos岛上的*应该是人人平等的吧，而ZKServer好像有一个Leader的概念。没错，其实Leader的概念也应该属于Paxos范畴的。如果*人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos的作者Lamport在他的文章”ThePart-TimeParliament“中阐述了这个问题并给出了解决方案——在所有*中设立一个总统，只有总统有权发出提议，如果*有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。
  总统——ZKServerLeader
又一个问题产生了，总统怎么选出来的？
  现在我们假设总统已经选好了，下面看看ZKServer是怎么实施的。

情况一：
  屁民甲(Client)到某个*(ZKServer)那里询问(Get)某条法令的情况(ZNode的数据)，*毫不犹豫的拿出他的记事本(localstorage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统Sync一下再告诉你。
情况二：
  屁民乙(Client)到某个*(ZKServer)那里要求*归还欠他的一万元钱，*让他在办公室等着，自己将问题反映给了总统，总统询问所有*的意见，多数*表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。
情况三：
  总统突然挂了，*接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间*停业，拒绝屁民的请求。 一般都是推举自己。
  呵呵，到此为止吧，当然还有很多其他的情况，但这些情况总是能在Paxos的算法中找到原型并加以解决。这也正是我们认为Paxos是Zookeeper的灵魂的原因。当然ZKServer还有很多属于自己特性的东西：Session,Watcher，Version等等，需要我们花更多的时间去研究和学习。

1.3、为什么使用zookeeper

　　大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）

　　目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制

　　协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器

　　提供通用的分布式锁服务，用以协调分布式应用

　　　　keepalived监控节点不好管理

　　　　keepalive采用优先级监控【没有协同工作、功能单一】

　　　　keepalive可扩展性差

1.4、zookeeper优点

特点	说明
最终一致性	为客户端展示同一个视图
可靠性	如果消息被到一台服务器接受，那么他将被所有的服务器接受
实时性	zk不能保证两个客户端能同时得到刚更新的数据，如果需要 最新数据，应该在读数据之前调用sync接口
独立性	各个client之间不干预
原子性	更新只能成功或者失败，没有中间状态
顺序性	所有server，同一消息发布顺序一致

1.5、zookeeper的工作原理

1、每个server在内存中存储了一份数据；定期落地

2、zookeeper启动时，将从实例中选举一个leader（Paxos协议）

3、leader负责处理数据更新等操作

4、一个更新操作成功，当且仅当大多数Server在内存中成功修改数据

1.6、zookeeper能作什么

　　Hadoop中使用zk的事件处理确保整个集群只有一个NameNode，存储配置信息等

　　Hbase中使用zk的事件处理确保整个集群只有一个HMaster，察觉HRegionServer联机和宕机，存储访问控制列表等。