yield-bytes

1、前言

  前面的博客中链接已经给出Hadoop3.1.2和yarn的完整部署（但还不是高可用），此篇博客将给出Hadoop的高可用部署，以及HBase高可用，为之后应用数据层开发提供底层的BigTable支持。前面的文章，我们已经深入讨论的ZooKeeper这个中间件的原理以及分布式锁的实现，事实上zookeeper使用最广泛的场景是“选举”主从角色，Hadoop以及Hbase的高可用（主从架构）正是通过ZooKeeper的临时节点机制实现。
以下的配置会跳过Hadoop3.1.2的部署，仅给出ZooKeeper分布式物理方式部署、以及HBase的部署过程、测试结果。

2、ZooKeeper与Hadoop、HBase的关系

  ZooKeeper作为协调器，在大数据组件中提供：管理Hadoop集群中的NameNode、HBase中HBaseMaster的选举，节点之间状态同步等。例如在HBase中，存储HBase的Schema，实时监控HRegionServer，存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个Master。

3、Hadoop与HBase的关系

  完整的hadoop组件环境架构图

1、MR基本定义

  参考百度百科定义，简要概括如下：
MapReduce是分布式的计算框架或者解决方案，大致有基本内容：

• 1）首先MapReduce重点是工作在集群的节点上，而非在单台服务器上做计算、做统计等
• 2）MapReduce把用户提交的任务以分布式放在多个节点上执行，自动划分计算数据和计算任务等，这些并行计算涉及到的系统底层的复杂细节交由MR框架负责处理。换句话：数据开发人员只需要定义“我要统计词频”的“任务”后，提交给MR框架即可，坐等计算结果，至于MR是如何从多台服务上找数据文件、计算统计、缓存中间计算结果、存储最终技术结果、CPU、内存、IO网络资源使用等，数据开发人员都无需关注，MR自己会处理。

1、Hadoop是一种具体的技术吗？

  准确的说，Hadoop是一套大数据的解决方案或者技术栈，不仅仅特指某种大数据技术，由Apache基金会上多个与大数据有关的明星组件构成，包括HDFS（分布式文件系统），YARN（分布式资源调度系统），MapReduce（分布式计算系统）、Spark、Hive、Hbase、Mahout、Zookeeper、Flume等，如下图所示。

  在此文章《基于Centos7.5完整部署分布式Hadoop3.1.2》里，已经给出详细的hadoop和yarn的部署过程，既然已经解决了大数据开发中“hdfs”的数据存储部署，那么就要考虑如何基于底层分布式文件基础上运行计算框架，以便进行更高层次的应用开发。在本篇文章中，将给出完整部署spark计算框架集群。

  本文基于虚拟机以及有限的计算资源搭建了非HA模式下分布式的hadoop集群，主要是为了后续开发基于大数据的实时计算项目提供hadoop服务。

1、相关安装包以及规划

考虑本地测试使用，这里所使用的三台服务器均有虚拟机创建，每台配置：1个vCPU+1G内存+9G硬盘，基本组件版本

  在前面的文章中，已经实现单实例redis分布式锁，但这种实现是基于单个redis服务，若redis服务不可用，显然所有客户端无法加锁，该实现还未到高可用的水平，因此需要进一步提升分布式的锁的逻辑，好在redis官方提供了相应的权威描述并称之为Redlock，具体参考文章：DLM，这个锁的算法实现了多redis实例（各个redis是相互独立的，没有主从、集群模式）的情况，实现了真正高可用分布式锁。

  zookeeper的分布式方案当然最优雅也最可靠，如果redis集群服务已经搭起或者哨兵模式已经部署的条件下，那么基于多个redis实例实现的分布式锁同样高可用，而且redis性能凸显，本文给出的是在单个redis服务上使用setnx+expire实现可用的分布式锁，也可使用redis的事务MULTI+WATCH机制实现分布式锁，只不过这种方式相对简单，本文不再赘述。

1、Part I

这里主要讨论redis集群数据分片的内容

1.1 为何使用redis-cluster模式？

1）首先避免单点故障，本人项目中用了主从模式，但因并发量不高，而且在redis不可用条件下，可以直接去数据库拿数据，所以还未部署集群模式。

2）redis官方给出单服务最高可以达到每秒执行10万条命令的性能，其实这对于绝大部分项目都够用了，这里给出集群模式的讨论，一为了深入了解redis，二是如果有一种需求需要百万/s的操作，显然redis单服务无法满足需求

3）内存吃满，redis首先将数据写在内存中，同时不定时异步持久化存在硬盘，一般服务器32G、64G、128G内存，若redis接收的数据量高达1T，128G内存的高性能服务器也会崩溃，故需要做

数据分片（sharding），分别存储在多个redis服务器中，这就需要redis集群模式支持了，这不就是经典的分布式数据库思想吗！

  在前面的文章中，已经给出基于kazoo操作zk的逻辑，接下来利用zk的临时序列节点机制实现分布式锁，分布式锁场景使用非常广，在读写方面都非常适合，个人认为比基于redis实现的分布式锁更具可靠性（但性能方面，redis应该更强？）。

  随着对zk使用和了解更深入，不得不佩服Apache基金出品的技术，一直拥有着改变世界的能量！zookeeper结合大数据技术栈，实现无以伦比的高可用分布式大数据架构，单单这一点就非常让人兴奋，从zk的设计来看，传统的数据结构和算法以及底层网络知识和技术，仍然可以通过结合现代业务模型进行创造和创新，所有继续保持沉淀传统基础，以助力更高效吸收新技术！

  以下引用了网上一些对zk的总结，内容比较简单，毕竟不是原理探讨，但对于zk的特性使用或者说发挥zk的特长，需要开发者深度理解数据模型或应用场景才能实现基于zk特性的相应逻辑。一些常用的zk特性和场合说明整理放在个人blog上，以便查阅