Zookeeper
Zookeeper是什么
-zookeeper是一个开源的分布式应用程序协调服务
Zookeeper能做什么
-Zookeeper是用来保证数据在集群间的事务一致性
死锁：A程序抢到了X资源，B抢到了Y资源，但是AB都需要XY资源才能往下处理，否则不会释放资源，抢到的资源也不会给别人用，就会造成死锁
单机的解决办法
Zookeeper应用场景
-集群分布式锁
-集群统一命名服务
-分布式协调服务
角色与特性
Zookeeper角色与特性
-Leader：接受所有Follower的提案请求并统一协调发起提案的投票，负责与所有的Follower进行内部数据交换
-Follower：直接为客户端服务并参与提案的投票，同时与Leader进行数据交换
-Observer：直接为客户端服务单不参与提案的投票，同时也与Leader进行数据交换
角色与选举
Zookeeper角色与选举
-服务在启动的时候是没有角色的（LOOKING）
-角色是通过选举产生的
-选举产生一个Leader，剩下的是Follower
选举Leader原则
-集群中超过半数机器投票选择Leader
-假如集群中拥有n台服务器，那么Leader必须得到n+1/2台服务器的投票
Zookeeper角色与选举
-如果Leader死亡，重新选举Leader
-如果死亡的机器数量达到一半，则集群挂掉
-如果无法得到足够的投票数量，就重新发起投票，如果参与投票的机器不足n/2+1，则集群停止工作
-如果Follower死亡过多，剩余机器不足n+1/2，则集群也会停止工作
-Oberserver不计算在投票总设备数量里面
Zookeeper原理与设计
Zookeeper可伸缩扩展性原理与设计
-Leader所有写相关操作
-Follower写操作与响应Leader提议
-在Observer出现以前，Zookeeper的伸缩性由Follower来实现，我们通过添加Follower节点的数量来保证Zookeeper服务的读性能，但是随着Follower节点数量的增加，Zookeeper服务的写性能收到了影响（写操作要通过Follower同意）
Zookeeper可伸缩扩展性原与设计
-客户点提交一个请求，若是读请求，则由每台Server的本地副本数据库直接响应。若是写请求，需要通过一致性协议（Zab）来处理
-Zab协议规定：来自Client的所有写请求都要转发给ZK服务中唯一的Leader，由Leader根据该请求发起一个提议（Proposal）。然后其他的Server对该提议（Proposal）进行投票（Vote）。之后Leader对Vote进行收集，当Vote数量过半时Leader会向所有的Server发送一个通知消息。最后当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client的写请求作出回应
Zookeeper集群的安装配置
zookeeper官方手册
管理员命令 四个字母：
http://zookeeper.apache.org/doc/r3.4.13/zookeeperAdmin.html#sc_zkCommands
案例
什么是Kafka
Kafka是什么
-Kafka是有LinkedIn开发的一个分布式的消息系统
-Kafka是使用Scala编写
-Kafka是一种消息中间件
为什么要使用Kafka
-解耦、冗余、提高扩展性、缓冲
解耦：类似卖房的人中介和买房人，有了中介，卖房可以不和买房人见面，处理问题靠中介
-保证顺序，灵活，削峰填谷
-异步通信
比如：爽11限时抢购时，可能会在短短几分钟内访问量请求量达到一个巨大的高峰，Kafka可以让同时请求数据分摊到几分钟或更多
Kafka角色
Kafka角色与集群结构
-producer：生产者，负责发布消息
-consumer：消费者，负责读取处理消息
-topic：消息的类别
-Parition：每个Topic包含一个或多个Partition
-Broker：Kafka集群包含一个或多个服务器
Kafka通过Zookeeper管理集群配置，选举Leader
Kafka集群安装与配置
案例
为什么需要NameNode
原因
-NameNode是HDFS的核心配置，HDFS又是Hadoop核心组件，NmaeNode在Hadoop集群中至关重要
-NameNode宕机，到时集群不可用，如果NameNode数据丢失将导致整个集群的数据丢失，而NameNode数据丢失将导致整个集群的数据丢失，而NameNode的数据的更新又比较频繁，实现NameNode高可用势在必行
解决方案
官方提供了两种解决方案
-HDFS with NFS
-HDFS with QJM
两种方式异同
HA方案对比
-都能实现热备
-都是一个Active NN和一个Standby NN
-都是用Zookeeper和ZKFC来实现自动失效恢复
-失效切换都是用Fencin配置的方法来Active NN
-NFS数据共享变更方案吧数据存储在共享存储里，我们还需要考虑NFS的高可用设计
-QJM不需要共享存储，但需要让每一个DN都知道两个NN的位置，并把块信息和心跳包发送个Active和Standby这两个NN
使用方案
使用原因（QJM）
-解决NameNode单点故障问题
-Hadoop给出了HDFS的高可用HA方案：HDFS通常由于两个NameNode组成，一个处于Active状态，另一个处于Standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步Active NameNote的状态，以便能够在他失败时进行切换
典型的HA集群
-NameNode会被配置在两台独立的机器上，在任何时候，一个NameNode处于活动状态，而另一个NameNode则处于备份状态
-活动状态的NameNode会响应集群中所有的客户端，备份状态的NameNode只是作为一个副本，保证在必要的时候提供一个快速的转移
NameNode高可用
NameNode高可用架构
-为了让Standby Node与Active Node保持同步，这两个Note都与一组称为JNS的互相独立的进程保持通信（Journal Nodes）。当Active Node更新了namespace，他将记录修改日志发送个JNS的多数派，Standby Node将会从JNS中读取这些edits，并持续关注他们对日志的变更
-Standby Node将日志变更应用在自己的namespace中，当Failover发生时，Standby将会在提升自己为Active之前，确保能够从JNS中读取所有的edits，即在Failover发生之前Standy持有的namespace与Active保持完全同步。NameNode更新很频繁，为了保持主备数据的一致性，为了支持快速Failover，Standby Node持有集群中blocks的最新位置是非常必要的，为了达到这个目的，DataNodes上需要同时配置这两个Namenode的地址，同时和他们都简历心跳连接，并把block位置发送给他们
NameNode高可用架构图
系统规划
hadoop中的
案例
高可用验证
案例
