大数据学习

1、Zookeeper

1.1 Zookeeper概念

Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。

1.2 Zookeeper角色

Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种：

1. Leader：
   ① 一个Zookeeper集群同时只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。
   ② 所有的写操作必须要通过Leader完成再由Leader将写操作广播给其他服务器。只要有超过半数节点（不包括observer节点）写入成功，该请求就会被提交。
2. Follower：
   ① 一个Zookeeper集群可能存在多个Follower，它会响应Leader的心跳。
   ② Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理。
   ③ 并且负责在Leader处理写请求时对请求进行投票。
3. Observer：
   角色与Follower类似，但是无投票权。Zookeeper需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server；Server增多，投票阶段延迟增大，影响性能；引入Observer，Observer不参与投票；Observer接收客户端的连接，并将写请求转发给Leader节点；加入更多的Observer节点，可以提高伸缩性，同时不影响吞吐率。
4. ZAB协议
   事务编号Zxid（事务请求计数器+epoch）
   在ZAB（Zookeeper Atomic Broadcast，ZooKeeper原子消息广播协议）协议的事务编号Zxid设计中，Zxid是一个64位的数字，其中低32位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加1；而高32位则代表Leader周期epoch的编号，每个当选产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务的ZXID，并从中读取epoch值，然后加1，以此作为新的epoch值，并将低32位从0位开始计数。
   Zxid（Transaction id）类似于RDBMS中的事物ID，用于标识一次更新操作的Proposal（提议）ID。为了保证顺序性，该zkid必须单调递增。
   epoch
   epoch：可以理解为当前集群所处的年代或者周期，每个leader就像皇帝，都有自己的年号，所以每次改朝换代，leader变更之后，都会在前一个年代的基础上加1。这样就算旧的leader崩溃恢复之后，也没有人听他的了，因为follower值听从当前年代的leader的命令。
   ZAB协议有两种模式：恢复模式（选主）和广播模式（同步）
   ZAB协议有两种模式，当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
5. ZAB协议4阶段
   ① Leader election（选举阶段）：节点在开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准leader。只有到达广播阶段，准leader才会成为真正的leader。这一阶段的目的就是为了选出一个准leader，然后进入下一个阶段。
   ②Discovery（发现阶段：接受提议、生成epoch、接受epoch）：在这个阶段followers跟准leader进行通信，同步followers最近接收的事务提议。这个阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch，让followers接受，更新它们的accepted Epoch。一个follower只会连接一个leader，如果有一个节点 f 认为另一个follower p是leader，f 在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入重新选举阶段。
   ③Synchronization（同步阶段：同步follower副本）：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有副本。只有当大多数节点都同步完成，准leader才会成为真正的leader。follower值会接收zxid比自己的lastZxid大的提议。
   ④Broadcast（广播阶段）：到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

ZAB协议JAVA实现（FLE发现阶段和同步合并为Recovery Phase（恢复阶段））
协议的Java版本实现跟上面的定义有些不同，选举阶段使用的是Fast Leader Election（FLE），它包含了选举的发现职责。因为FLE会选举拥有最新提议历史的节点作为leader，这样就省去了发现最新提议的步骤。实际的实现将发现阶段和同步合并为Recovery Phase（恢复阶段）。所以，ZAB的实现只有三个阶段：Fast Leader Election; Recovery Phase; Broadcast Phase.

6. 投票机制
   每个server首先给自己投票然后用自己的选票和其他server选票对比，权重大的胜出，使用权重较大的更新自身选票箱。
7. Zookeeper工作原理（原子广播）
   ①Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
   ②当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
   ③状态同步保证了leader和server具有相同的系统状态
   ④一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入Zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。

Kafka

Kafka概念

Kafka是一种高吞吐、分布式、基于发布/订阅的消息系统，最初由Linkedln公司开发，使用Scala语言编写，目前是Apache的开源项目。

1. broker：kafka服务器，负责消息存储和转发
2. topic：消息类别，Kafka按照topic来分类消息
3. partition：topic的分区，一个topic可以包含多个partition，topic消息保存在各个partition上
4. offset：消息在日志中的位置，可以理解是消息在partition上的偏移量，也是代表改消息的唯一序号
5. producer：消息生产者
6. consumer：消息消费者
7. consumer group：消费者分组，每个consumer必须属于一个group
8. Zookeeper：保存着集群broker、topic、partition等meta数据，另外还负责broker故障发现，partition leader选举，负载均衡等功能。