hadoop的HA机制-ql

 非HA架构： 

可靠性有保障；

但是服务的可用可用性不高；

HA架构

1.edits抽取出来搭建一个集群，保证高可用，分布式应用，管理edits，叫做qjournal,底层依赖zookeeper实现，每个节点叫做qjournalnode

2.状态切换问题：

如何进行状态的切换，感知？

1）可以使用zookeeper进行管理，哪台NN是active，哪个是standby

2）在NN上启动一个监控进程，时刻监控本地的NN是否正常，NN向zookeeper中注册数据，这个状态管理进程ZKFC，也是使用zookeeper管理

如何避免状态切换时发生brain split 脑裂现象？

脑裂：例如某个NN假死，standby的NN感知到了，变为active，那么就存在了两个active了

当standby的NN感知到了active的NN宕机了，就会发送ssh kill -金马在线注册:www.jinmazx.cn 9 进程号 进行杀死active的NN，收到返回值，就会切换状态变为active，这样就能防止脑裂

发送ssh不一定成功，这就出现另一个问题

可以执行自定义shell脚本程序，当超时之后进行状态切换。

fencing机制：

①优亿在线:www.jintianxuesha.com 发送kill指令

②百事2:www.baihuayl7.cn 自定义shell脚本

Federation

几个NN组成一个联邦，客户端访问优先是访问一个Federation

用于监视和控制namenode进程。ZKFC是基于Zookeeper实现的

谈到RPC肯定绕不开TCP通信，而主流的RPC框架都依赖于Netty等通信框架，这时候我们还要考虑是使用长连接还是短连接：

• 短连接：每次通信结束后关闭连接，下次通信需要重新创建连接；优点就是无需管理连接，无需保活连接；
• 长连接：每次通信结束不关闭连接，连接可以复用，保证了性能；缺点就是连接需要统一管理，并且需要保活；

主流的RPC框架都会追求性能选择使用长连接，所以如何保活连接就是一个重要的话题，也是本文的主题，下面会重点介绍一些保活策略；

为什么需要保活

上面介绍的长连接、短连接并不是TCP提供的功能，所以长连接是需要应用端自己来实现的，包括：连接的统一管理，如何保活等；如何保活之前我们了解一下为什么需要保活？主要原因是网络不是100%可靠的，我们创建好的连接可能由于网络原因导致连接已经不可用了，如果连接一直有消息往来，那么系统马上可以感知到连接断开；但是我们系统可能长时间没有消息来往，导致系统不能及时感知到连接不可用，也就是不能及时处理重连或者释放连接；常见的保活策略使用心跳机制由应用层来实现，还有网络层提供的TCP Keepalive保活探测机制；

TCP Keepalive机制

TCP Keepalive是操作系统实现的功能，并不是TCP协议的一部分，需要在操作系统下进行相关配置，开启此功能后，如果连接在一段时间内没有数据往来，TCP将发送Keepalive探针来确认连接的可用性，Keepalive几个内核参数配置：

• tcp_keepalive_time：连接多长时间没有数据往来发送探针请求，默认为7200s（2h）；
• tcp_keepalive_probes：探测失败重试的次数默认为10次；
• tcp_keepalive_intvl：重试的间隔时间默认75s；

以上参数可以修改到/etc/sysctl.conf文件中；是否使用Keepalive用来保活就够了，其实还不够，Keepalive只是在网络层就行保活，如果网络本身没有问题，但是系统由于其他原因已经不可用了，这时候Keepalive并不能发现；所以往往还需要结合心跳机制来一起使用；

心跳机制

何为心跳机制，简单来讲就是客户端启动一个定时器用来定时发送请求，服务端接到请求进行响应，如果多次没有接受到响应，那么客户端认为连接已经断开，可以断开半打开的连接或者进行重连处理；下面以Dubbo为例来看看是如何具体实施的；

hadoop的HA机制-ql

原文：https://www.cnblogs.com/woshidanzi/p/12862505.html