常用组件 、 Kafka集群 、 Zookeeper总结和答疑

 

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中的

 

案例

 

高可用验证

案例