大数据&&Zookeeper学习笔记（1）

大数据概念

  大数据是指无法在一定时间范围内用常规的软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高速增长率和多样化的信息资产。其特点是Volume（海量）、Velocity（高速）、Variety（多样）、Value（价值）。

• 海量：相对于传统意义上的数据量来说，大数据所涉及到的数据量很大，且在动态变化和快速增长。
• 高速：大数据对数据处理及相应速度有严格要求。
• 多样：大数据的数据来源多，数据类型多且数据关联性强。
• 价值：大量数据所包含的信息对未来趋势和模式的可预测分析具有巨大的价值。

Zookeeper 学习笔记

分布式系统的定义

  分布式系统的定义为：分布式系统是同时跨越多个物理主机，独立运行多个软件所组成的系统。分布式系统能够利用多处理器的运算能力来运行组件。
  主—从架构为分布式系统中一个得到广泛应用的架构，在该架构中，主节点进程负责跟踪从节点状态的任务，并分配任务到从节点。从节点进程负责完成任务。

ZooKeeper概念

  Zookeeper是一个开源的分布式协调服务框架，主要来解决分布式集群中应用系统的一致性问题和数据管理问题。

  当多个主机中的进程访问位于不同主机的共享资源时，涉及到网络问题，需要使用分布式锁，这也是Zookeeper要解决的问题。Zookeeper本质上是一个分布式文件系统，适合存放应用协作的关键数据或配置文件。Zookeeper不适合存放海量数据，对于需要存储海量数据的情况，应该使用数据库或分布式文件系统。
  不论数据在哪台主机上，Zookeeper对外都提供了统一的访问路径，Zookeeper对外提供了一个类似文件系统的视图，可以通过操作文件系统的方式操作Zookeeper。该文件系统中的节点叫znode，它既可以存储数据也可以有子节点，具备目录与文件的特性。

Zookeeper操作

• 使用路径获取Znode
• 获取，修改Znode携带的数据
• 添加，删除Znode

Zookeeper架构

  Zookeeper服务器端运行于两种模式下：独立模式与仲裁模式。在独立模式中只有一个单独的服务器，Zookeeper的状态无法复制。在仲裁模式下，具有一组Zookeeper服务器，称为Zookeeper集群，它们之间可以进行状态复制，并同时服务于客户端请求。
  在仲裁模式下，必须保证有集群中有多数的服务器可以正常运行。例如某个集群中有5台服务器，为了能够正常工作，必须保证有三个服务器可用。
  在Zookeeper集群中，有三个角色：Follower，Leader与Observer

  Follower：Follower只能处理非事务请求（例如读请求），将事务请求（例如写请求）转发至Leader。一个Zookeeper可能存在多个Follower，它会响应Leader的心跳，负责对Leader处理写请求时对请求进行投票。
  Leader：一个Zookeeper集群同一时间只有一个实际工作的Leader，它会维护并发起与各Follower之间的心跳。所有写操作必须通过Leader完成，再由Leader将写操作广播到其他服务器。
  Observer：角色与Follower类似，但无投票权。

Zookeeper会话

  在对Zookeeper执行任何请求前，一个客户端必须先与服务器建立会话（session），客户端提交给Zookeeper的所有操作均关联在会话上。会话的生命周期如图

一个会话从NOT_CONNECTED状态开始，当Zookeeper客户端初始化后转换到CONNECTING状态（1）。正常情况下，当客户端与Zookeeper服务器建立连接后转换到CONNECTED状态（2），此时可以向Zookeeper服务器发送指令。当客户端与服务器断开连接或无法收到服务器的响应时，session重新回到CONNECTING状态（3）。如果可以重连到服务器，服务器确认会话有效后便回到CONNECTED状态。否则将声明会话过期，转换到CLOSE状态（4）。应用也可以显式关闭会话（5）。

Zookeeper应用场景

1. 数据发布/订阅系统
     客户端向服务器订阅节点，一旦节点发生改变，服务端就会向客户端推送通知，之后客户端向服务器获取最新数据。数据发布/订阅系统可以动态获取数据，实现配置信息的集中式管理和数据的动态更新。
   
     客户端订阅某一Znode，当原数据改变时，Zookeeper集群通知Client发生变化，Client向原数据索要数据。
2. 命名服务
     客户端可以根据指定名字来获取资源的实体，Zookeeper可以实现一套分布式全局唯一的ID分配机制
3. 分布式协调/通制
     心跳检测：不同机器间确保对方是否正常运行。可以让不同机器都在Zookeeper的一个指定节点下创建一个临时子节点，不同机器之间根据临时子节点判断对应客户端是否存活。

    工作进度汇报：Zookeeper上选择一个节点，每个客户端需要在节点下创建临时子节点，各机器可将任务执行进度写到临时节点中去，使中心系统能够获得任务的执行进度。
    系统调度：控制台需要将指令信息发送给所有的客户端，控制其进行相应的业务逻辑。后台人员在控制台做一些操作，实际上就是修改Zookeeper上某些节点数据，Zookeeper可以把数据变更以时间通知形式发送给订阅客户端。
4. 分布式锁

• 排它锁/写锁：当某事务对某数据对象添加写锁后，只有该事务能够对该数据对象进行读和写操作，其他事务均不能对该数据对象进行读/写操作，直到该事务释放写锁。
  • 获取锁：在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock，Zookeeper可以保证只有一个客户端创建成功，没有成功的客户端要注册/exclusive_lock节点监听。
  • 释放锁：客户端宕机或完成业务逻辑后会删除临时节点，此时所有/exclusive_lock节点上注册监听的客户端会收到通知，可以重新发起分布式锁获取。
• 共享锁/读锁：当某事务对某数据对象添加读锁后，该事务可以进行读操作，但不能进行写操作，其他事务对象也可以对该数据对象添加读锁，但不能添加写锁。
  • 需要共享锁时，所有的客户端都会到/shared_lock下面创建一个临时顺序节点。
• 分布式队列：在分布式环境下，我们同样需要一个类似单进程队列的组件，实现跨进程、跨主机、跨网络的数据分享和数据传递，这就是分布式队列。例如A将Hadoop集群计算的结果交给B继续计算，B完成任务后交给C，以此类推。这样就想一个工作流一样，一环一环地传下去，此时就需要一个分布式队列来进行数据分享和数据传递。

Zookeeper的使用实例

  在大数据分析和存储框架中Apache Hadoop中，Zookeeper可以同时保证HDFS与MapReduce的高可用。Zookeeper可以通过心跳检测机制检测NameNode节点服务器与ResourceManager节点服务器是否宕机，当这两个服务器宕机时，Zookeeper可以通过Watch机制来通知备用的NameNode服务器与ResourceManager服务器工作，进而达到高可用的目的。

Zookeeper选举机制

  Zookeeper的Leader选举机制是保证数据一致性的关键，需要在服务器启动和服务器运行期间选举Leader。

服务器启动时选取Leader

  当服务器集群中有两台服务器启动，便可以进行Leader选举。选举过程如下：

• 每个Server发出一个投票：设服务器1为Server1，服务器2为Server2。当服务器启动时，每一台主机都会把自己作为Leader服务器进行投票，此时会生成下表。其中myid代表服务器权值，权值越大，选举时占的优势越强。zxid代表事务id，该值越大，表示数据库越新，选举时的优势就越强。

服务器	myid	zxid
Server1	1	0
Server2	2	0

  然后服务器会将各自的投票发给集群中的其他服务器。

• 接受来自各个服务器的投票：集群中的每个服务器收到投票后，先判断该投票的有效性，如检查本轮投票是否阿里子Looking状态的服务器。
• 处理投票：针对每个投票，服务器需要将别人的投票和自己的投票进行比较，比较规则如下：
  • 优先检查zxid，zxid较大的服务器优先作为Leader。
  • 若zxid相同，比较myid。myid较大的服务器作为leader。
• 统计投票：每次投票后，服务器会统计投票信息，判断是否有过半机器收到相同的投票信息。比较哪个服务器的票数多，选举哪个服务器作为Leader。
• 改变服务器状态：确定Leader之后，每个服务器更新自己的状态，确定自己在Zookeeper集群中的角色（Leader，Follower）。Follower的状态为Following，Leader的状态为Leading。
  
  服务器运行时选取Leader与服务器启动时选取Leader方法相同