HDFS、Kafka、HBase、Redis 实现 HA 方式的总结

推荐阅读：redis系列之——高可用（主从、哨兵、集群）

1. 概述

首先需要明确，什么时候需要实现 HA（高可用）？

只有当出现 单点故障问题 的时候，例如：

• HDFS：客户端请求写文件时，需要请求 NameNode 返回元数据，但 NameNode 只有一个，假如宕机就需要切换到备用的 NameNode
• Kafka：使用了主从模式，1个 leader 和多个 follower 之间需要同步数据，假如 leader 宕机，就需要重新选举 leader
• Hbase：由于数据是存在 HDFS 上的，所以不需要同步数据，但 Hbase 分为两种角色：1个 HMaster 和多个 HRegionServer。假如 HMaster 宕机，就需要重新选举 HMaster
• Redis：使用了主从模式，1个 leader 和多个 follower 之间需要同步数据，假如 leader 宕机，就需要重新选举 leader

Hadoop 生态圈中，实现 HA 一般都是利用 Zookeeper，充当哨兵的角色。

---

2. HDFS

HDFS 实现 HA 是这几个中最特殊的，由于仅有两个 NN（主和备），所有并没有另外设置一个类似于 Kafka 中的 Controller 角色来实现状态切换。

HDFS 是在每个 NN 中都启动一个 ZKFC 进程，利用 ZKFC 进程来监控 NN 进程。假如 NN 进程出问题了，那么 ZKFC 就通过 Zookeeper 来切换主备状态。

---

3. Kafka

在 Kafka 集群中会有一个或者多个 Broker，其中有一个 Broker 会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。

当某个分区的 Leader 出现故障时，由控制器负责为该分区选举新的 Leader 。

Kafka 中的控制器选举的工作依赖于 Zookeeper，成功竞选为控制器的 Broker 会在 ZooKeeper 中创建临时节点。

---

4. HBase

当用户需要从 HBase 中读写数据时，直接向 Zookeeper 请求，然后与 HRegionServer 通信，中间不需要经过 HMaster。

所以，HBase 中的 HMaster 其实就已经有点像 Kafka 中的 Controller 角色了，它负责监控 HRegionServer。

当 HMaster 宕机时，也是依赖于 Zookeeper 来重新选举新的 HMaster。

---

5. Redis

Redis 和 Kafka 很像，都是1个 leader 和多个 follower 之间同步数据，假如 leader 宕机了，就需要重新选举 leader。

但区别是，Kafka 直接使用 Hadoop 生态圈的 ZK 实现，而 Redis 中使用的是哨兵机制（Sentinel）。

Redis 会设置多台机器为哨兵，对集群进行监控，当发现 leader 宕机的时候，哨兵之间就会重新选举出新的 leader。