1. 大数据是什么?
1.1 大数据就是4V的特征
Volume (大量) , Velocity (高速) , Variety (多样) , Value (价值) , 即数据体量巨大, 数据类型繁多, 价值密度低, 处理速度快.
1.2 JavaEE开发与大数据的区别
1.2.1 JavaEE开发流程
1.2.2 大数据开发流程
1.2.3 两者区别
1) 架构层面
javaEE体系: 三层架构, 表现层 (Web) 业务层 (Service) 持久层 (Dao) .
大数据体系: 围绕数据, 数据采集 (数据源) , 数据存储, 数据计算 (分析) , 数据展示.
2) 技术层面
JavaEE: 成熟, 解决方案多, 技术点集中.
大数据: 相对年轻, 迭代更新快, 解决方案相对少, 技术相当繁琐, 杂, 碎.
3) 开发层面
JavaEE: 代码量很大, 偏向业务, 运维等任务相对较少, 固定搭配, 习惯用法较多.
大数据: 代码量很少, 偏向技术 (原理, 知识) , 运维任务略多 (集群, 服务器等) , sql数据分析, 类sql, hql.
4) 市场层面
javaEE: 很成熟, 有自己的行业规范, 如日中天
大数据: 市场起步阶段, 规范有待健全, 朝阳产业 (结合人工智能, 机器学习等) .
2. Apache Zookeeper
2.1 Zookeeper概述
Zookeeper是一个分布式协调服务的开源框架. 主要用来解决分布式集群中应用系统的一致性问题.
Zookeeper本质上是一个
分布式的小文件存储系统. 提供基于类似于文件系统的目录树方式的数据存储, 并且可以对树种的节点进行有效管理.
维护和监控你存储的数据的状态变化, 通过监控这些数据状态的变化, 从而可以达到基于数据的集群管理.
分布式程序, 可以多台服务器部署 (可靠, 稳定) .
Zookeeper是一个主从结构集群.
2.2 Zookeeper特性
全局数据一致: 集群中每个服务器保存一份相同的数据副本, Client无论连接到哪个服务器, 展示的数据都是一致的, 这是最重要的特性.
可靠性: 如果消息被其中一台服务器接受, 那么将被所有的服务器接受.
顺序性: 包括全局有序和偏序两种: 全局有序是指如果一台服务器上消息a在消息b前发布, 则在所有Server上消息a都将在消息b前被发布. 偏序是指如果一个消息b在消息a后被同一个发送者发布, 消息a必将排在消息b前面.
数据更新原子性: 一次数据更新要么成功 (半数以上节点成功) , 要么失败, 不存在中间状态.
实时性: Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息, 或者服务器失效的信息
2.3 Zookeeper集群角色
Leader: Zookeeper集群工作的核心, 事务请求 (写操作) 的唯一调度和处理者, 保证集群事务处理的顺序性, 集群内部各个服务器的调度者.
对于create, setData, delete等有写操作的请求, 则需要统一转发给leader处理, leader需要决定编号, 执行操作, 这个过程称为一个事务.
Follower: 处理客户端非事务 (读操作) 请求, 转发事务请求给Leader. 参与集群Leader选举投票.
此外, 针对访问量较大的Zookeeper集群, 还可新增观察者角色.
Observer: 观察者角色, 观察Zookeeper集群的最新状态变化并将这些状态同步过来, 其对于非事务请求可以进行独立处理, 对于事务请求, 则会转发给Leader服务器进行处理. 不会参与任何形式的投票只提供非事务服务, 通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力.
可以分为主从主备两种方式:
主从: 主角色 leader
从角色 follower
常见的一主多从的架构 (storm, hadoop等) , 主从架构各司其职, 互相配合.
主备: 主角色 active
备角色 standby
主备角色常用于解决单点故障问题, 常见的是一主一备, 只有主角色发生故障时, 备角色才会切换成主角色, 同一个时刻只能有一个主角色.
2.4 Zookeeper集群搭建
Zookeeper集群搭建指的是Zookeeper分布式模式安装. 通常由2n+1台servers组成. 这是因为为了保证Leader选举 (基于Paxos算法的实现) 能过得到多数的支持, 所以Zookeeper集群的数量一般为奇数.
如果要想使用Observer模式, 可在对应节点的配置文件添加配置: peerType=observer, 其次必须在配置文件指定哪些节点被指定为Observer, 如: server. 1:hadoop01:2181:3181:observer
2.5 Zookeeper数据模型
Zookeeper的数据模型, 在结构上和标准文件系统非常相似, 拥有一个层次的命名空间, 都是采用树形层次结构, Zookeeper树中的每个节点被称为--Znode. 和文件系统的目录树一样, Zookeeper树中的每个节点可以拥有子节点. 但也有不同之处:
1) Zookeeper兼具文件和目录两种特点: 既像文件一样维护着数据, 元信息, ACL, 时间戳等数据结构, 又像目录一样可以作为路径标识的一部分, 并可以具有子Znode. 用户对Znode具有增删改查等操作 (权限允许的情况下) .
2) Znode具有原子性操作: 读操作将获取与节点相关的所有数据, 写操作也将替换掉节点的所有数据. 另外, 每一个节点都拥有自己的ACL (访问控制列表) , 这个列表规定了用户的极限, 即限定了特点用户对目标节点可以执行的操作.
3) Znode存储数据大小有限制: Zookeeper虽然可以关联一些数据, 但并没有被设计为常规的数据库或者大数据存储, 相反的是, 他用来管理调度数据, 比如分布式应用中的配置文件信息, 状态信息, 汇集信息等. 这些数据的共同特性就是他们都是很小的数据, 通常以KB为大小单位. Zookeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M, 当时常规使用中应该远小于此值.
4) Znode通过路径引用: 如同Unix中的文件路径. 路径必须是绝对的. 因此他们必须由斜杠字符开头. 除此以外, 他们必须是唯一的, 也就是说每一个路径只有一个表示, 因此这些路径不能改变. 在Zookeeper中, 路径由Unicode字符串组成, 并且有一些限制. 字符串"/zookeeper"用以保存管理信息, 比如关键配额信息.
2.6 数据结构图
图中的每个节点称为一个Znode. 每个Znode由3部分组成:
1) stat: 此为状态信息, 描述该Znode的版本, 权限等信息
2) data: 与该Znode关联的数据
3) children: 该Znode下的子节点
2.7 节点类型
Znode有两种, 分别为临时节点和永久节点
节点的类型在创建时即被确定, 并且不能改变
1) 临时节点: 该节点的生命周期依赖于创建他们的会话. 一旦会话结束, 临时节点将被自动删除, 当然也可以手动删除. 临时节点不允许拥有子节点.
2) 永久节点: 该节点的生命周期不依赖于会话, 并且只有在客户端显示执行删除操作的时候, 他们才能被删除.
Znode还有一个序列化的特性, 如果创建的时候指定的话, 该Znode的名字后面会自动追加一个不断增加的序列号. 序列号对于此节点的父节点来说是唯一的, 这样便会记录每个子节点创建的先后顺序. 他的格式为"%10d" .
这样便会存在四种类型的Znode节点, 分别对应:
1) 永久非序列化节点
2) 临时非序列化节点
3) 永久序列化节点
4) 临时序列化节点
2.8 节点属性
每个Znode都包含了一系列属性, 通过命令get, 可以获得节点的属性.
1) dataVersion: 数据版本号, 每次对节点进行set操作, dataVersion的值都会增加1 (即使设置的是相同数据) , 可有效避免了数据更新时出现的先后顺序问题.
2) cversion: 子节点的版本号. 当Znode的子节点有变化时, cversion的值就会增加1.
3) cZxid: Znode创建的事务id.
4) mZxid: Znode被修改的事务id, 即每次对Znode的修改都会更新mZxid.
对于Zookeeper来说, 每次的变化都会产生一个唯一的事务id, zxid (Zookeeper Transaction ID) . 通过zxid, 可以确定更新操作的先后顺序. 例如, 如果zxid1小于zxid2, 说明zxid1操作先于zxid2发生, zxid对于整个Zookeeper都是唯一的, 即使操作的是不同的Znode.
5) ctime: 节点创建的时间戳
6) mtime: 节点最新一次更新发生时的时间戳
7) ephemeralOwner: 如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id, 如果不是, ephemeralOwner值为0.
在Client和Server通信之前, 首先需要建立连接, 该连接称为session. 连接建立后, 如果发生连接超时, 授权失败, 或者显式关闭连接, 连接便处于CLOSED状态, 此时session结束.
2.9 Zookeeper Watcher (监听机制)
Zookeeper提供了分布式数据发布 / 订阅功能, 一个典型的发布 / 订阅模型系统定义了一种一对多的订阅关系, 能让多个订阅者同时监听某一个主题对象, 当这个主题对象自身状态变化时, 会通知订阅者, 使他们能够做出相应的处理.
Zookeeper中, 引入了Watcher机制来实现这种分布式的通知功能. Zookeeper允许客户端向服务端注册一个Watcher监听, 当服务端的一些事件触发了这个Watcher, 那么就会指定客户端发送一个事件通知来实现分布式的通知功能.
触发事件种类很多: 节点创建, 节点删除, 节点改变, 子节点改变等.
总的可以概括Watcher为三个过程:
1) 客户端向服务端注册Watcher
2) 服务端事件发生触发Watcher
3) 客户端回调Watcher得到触发时间情况
Watcher机制特点:
一次性触发: 事件发生触发监听, 一个WatcherEvent就会被发送到设置监听的客户端, 这种效果是一次性的, 后续再次发生同样的事件, 不会再次触发.
事件封装: Zookeeper使用WatchedEvent对象来封装服务端事件并传递.
WatcherEvent包含了每一个事件的三个基本属性: 通知状态 (KeeperState) , 事件类型 (EventType) , 节点路径 (path) .
event异步发送: Watcher的通知事件从服务端发送到客户端是异步的.
先注册再触发: Zookeeper中的Watch机制, 必须客户端先去服务端注册监听, 这样事件发送才会触发监听, 通知给客户端.
2.10 通知状态和事件类型
同一个事件类型在不同的通知状态中代表的含义有所不同.
其中连接状态事件 (type=None, path=null) 不需要客户端注册, 客户端只要有需要直接处理就行了.
2.11 Zookeeper选举机制
zookeeper默认的算法是FastLeaderElection, 采用投票数大于半数则胜出的逻辑.
服务器ID: 编号越大在选择算法中的权重越大
选举状态: LOOKING, 竞选状态
FOLLOWING: 随从状态, 同步leader状态, 参与投票
OBSERVING: 观察状态, 同步leader状态, 不参与投票
LEADING: 领导者状态
数据ID: 服务器中存放的最新数据version, 值越大说明数据越新, 在选举算法中数据越新权重越大
逻辑时钟: 也叫投票的次数, 同一轮投票过程中的逻辑时钟值是相同的. 每投完一次票这个数据就会增加, 然后与接收到的其他服务器返回的投票信息中的数值对比, 根据不同的值做出不同的判断.
2.11.1 全新集群选举
假设目前有5台服务器, 每台服务器均没有数据, 他们的编号分别是1, 2, 3, 4, 5, 按编号依次启动, 他们的选举过程如下:
1) 服务器1启动, 给自己投票, 然后发投票信息, 由于其他机器还没有启动所有他收不到反馈信息, 服务器1的状态一直属于LOOKING.
2) 服务器2启动, 给自己投票, 同时与之前启动的服务器1交换结果, 由于服务器2的编号大所以服务器2胜出, 但此时投票数没有大于半数, 所以两个服务器的状态依然是LOOKING.
3) 服务器3启动, 给自己投票, 同时与之前启动的服务器1, 2交换信息, 由于服务器3的编号最大所以服务器3胜出, 此时投票数正好大于半数, 所以服务器3称为Leader, 服务器1, 2成为Follower.
4) 服务器4启动, 给自己投票, 同时与之前启动的服务器1, 2, 3交换信息, 尽管服务器4的编号大, 但之前服务器3已经胜出, 所以服务器4只能成为Follower.
5) 服务器5启动, 后面的逻辑同服务器4成为Follower.
2.11.2 非全新集群选举
对于运行正常的zookeeper集群, 中途有机器down掉, 需要重新选举时, 选举过程就需要加入数据ID, 服务器ID, 逻辑时钟.
数据ID: 数据新的version就大, 数据每次更新都会更新version.
服务器ID: 就是我们配置的mvid的值, 每个机器一个.
逻辑时钟: 这个值从0开始递增, 每次选举对应一个值. 如果在同一次选举中, 这个值是一致的.
这样选举的标准就变成:
1) 逻辑时钟小的选举结果被忽略, 重新投票.
2) 统一逻辑时钟后, 数据id大的胜出.
3) 数据ID相同的情况下, 服务器ID大的胜出.
