Hadoop学习笔记：一致性服务系统Zookeeper_Mysql

Zookeeper背景

单节点的系统是不存在不一致情况的，分布式系统会出现不一致情况。在大规模集群中，各个节点在应用执行时会出现各种情况，造成在执行一个任务的时候，有些成功了，有些失败了，这样就出现了不一致的情况。比如A,B,C三个节点都存储了TEST=10，一个应用更新TEST=20，A和C成功了，B没成功，那么A和C认为TEST=20，而B认为TEST=10，这就出现了不一致情况。
Zookeeper是Google Chubby的开源实现，解决分布式集群中应用系统的一致性问题，类似于文件系统的目录节点树方式的数据存储，Hadoop中使用Zookeeper的系统有Yarn、HDFS、HBase和Kafka。

Zookeeper数据模型

类似于一个标准的文件系统，每个节点为一个Znode，每个 Znode 可以存储数据。Znode 可以被监控，一旦变化可以通知设置监控的客户端，包括存储的数据的修改和子节点目录的变化。
在这里插入图片描述
Znode可以类比文件，Znode类型包括永久节点、临时节点和顺序节点：
1）永久节点：永久节点建完以后永远存在，除非把它删除；
2）临时节点：一旦创建这个 Znode 的客户端与服务器失去联系，这个
Znode 也将自动删除，HDFS中的Active NameNode就是临时节点；
3）顺序节点：Znode 的名字可以自动编号，如App1已经存在，再创建的话将会自动命名为 App2，相当于分布式系统中的读写锁：读的时候，写要等待；写的时候，读要等待。

Zookeeper架构

Zookeeper集群主要角色有Leader，Follower，Observer
在这里插入图片描述

Leader
领导者，负责投票的发起和决议，以及更新系统状态，读写是由Leader来主持，Leader协调各个节点；
Follower
接受客户端的请求并返回结果给客户端，参与投票，Leader有什么变化，Follower跟着做，比如Leader往A里写入10，Follower就跟着更新状态，Follower有全局视图，具有完整的状态，但Follower不能写，写只能由Leader来做。Leader是投票选举出来的，谁状态最新，被投票达到半数以上的是Leader，广播出去后，其余自动变为Follower ；
Observer
接受客户端的请求，将写的请求转发给Leader，不参
与投票。

Zookeeper生产环境一般部署五个节点（服务器）：

初始化
各个节点同时启动，状态TXID（是一个全局的变量，节点有一次操作，它就会自动加1）都是0，谁的TXID大，谁就最有可能成为Leader；如果是一个已经使用过的集群，哪个节点的TXID最大，说明它拥有最新的数据，它就很可能成为Leader。
数据更新
客户端提出写数据的请求，如果正好提交给了Leader，那么Leader就会直接执行写操作，如果提交给了Follower，那么Follower就会转发写数据的请求给Leader，然后Leader再广播写请求到所有的节点，如果有半数以上的节点投票同意这个写操作，Leader就会执行这个写操作，并同步给Follower，只有半数以上的节点都更新了数据，这次更新才是有效的，才会通知客户端这次操作成功了，如果没有操作成功，会抛出异常返回。
数据读取
如果要读最新的数据（创建节点、文件更新都属于数据更新），需要从Leader读，这样会影响性能，也可以从Follower读，这种情况不能保证读到的是最新的数据。但一般情况下，Leader和Follower的数据是一样的。
安全性
因为，要保障Leader有最新的数据和视图。所以，Zookeeper的部署，不把所有节点放到一个机架上。一般性能和可靠性的折中，Zookeeper部署5个节点，5个节点中同时三台机器挂掉的几率是很小的（BAT一般部署五台服务器）。也有配置3个节点的，这样一旦一个出问题，需要立即修复。如果有Follower挂了，那等它恢复后，Leader会批量的把它挂机期间缺失的数据更新通知给它。

Zookeeper在分布式系统中的应用

Zookeeper是一致性服务系统，作为第三方，保证一致性。它可以应用到其它的分布式系统中，一般一个公司只维护一个Zookeeper集群，各个系统共享。

Zookeeper在HDFS中的应用
HDFS中Active NameNode和Standby NameNode的设定是由Zookeeper来定的。启动较快的NameNode在Zookeeper被选举成了Active NameNode 后，另外一个NameNode就成了Standby NameNode。Standby NameNode一直监控Active NameNode，一旦Active NameNode挂掉，它所在的节点（临时节点）就会消失，Standby NameNode监控到变化，就会把自己变为Active NameNode。Zookeeper作为第三方，保证一致性。确保NameNode的Active和Standby状态不会乱掉。如果没有Zookeeper作为第三方系统记录谁是Active谁是Standby，在分布式系统中容易出现脑裂，节点不清楚自己的状态，是Active或是Standby。
Active NameNode的元数据还是存在HDFS上，不会存在Zookeeper上，Zookeeper只负责选举谁是Active NameNode，以及记录谁是Active NameNode，谁是Standby NameNode。Zookeeper不适合写入大量数据，所有的读写都在Leader，它虽然类似一个文件系统，但只存储一些简单信息，HDFS上的信息存到Zookeeper，它承载不了。HDFS上数据交换还是通过JournalNode，类似Zookeeper的实现，是为HDFS优化开发的一个组件。
Zookeeper在Kafka中的应用
Kafka的Topic有多副本，这些副本也有主从的区别，这个主从的区分由Zookeeper来管理，所有的读写都由主Topic来完成，然后再同步到从Topic上，主Topic一旦挂了，就会有新的从Topic变为主Topic。Kafka也会通过判断哪个副本的Offset最大来选举谁是Leader。
一般Kafka会自带Zookeeper，启动的时候会自动启动一个Zookeeper。

Zookeeper使用场景

配置管理
配置信息保存在 Zookeeper 的某个目录节点中，所有的应用都监控配置信息的状态，一旦配置信息发生变化，应用就会收到 Zookeeper的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。配置管理一般使用永久节点，因为配置信息是人为创建，并人为修改的，所以只有人为删除，这个节点才会消失，所以是永久节点。
集群管理
如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它机器必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。集群管理一般使用临时节点，像HDFS中Active Namenode或是Kafka中Broker副本的选举。
负载均衡
每台服务器在启动时，向Zookeeper进行登记。服务的调用者到注册中心里面查找能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接。负载均衡一般使用临时节点，每台机器启动创建一个节点，挂掉这个节点就消失，所以它是个临时节点。
分布式锁
把Zookeeper上的一个Znode看作是一把锁，通过Create Znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。分布式锁一般使用临时节点，节点挂掉后，重新分配锁。