3.2 Hypertable

以Google 的BigTable相关论文为基础指导，采用与HBase非常相似的分布式模型，其目的是构建一个针对分布式海量数据的高并发数据库。

 

3.2.1 概述

Hypertable架构图：

核心组件：

• • Hyperspace
    是保证Hypertable一致性的核心。类似于Google BigTable 系统中的Chubby
    这里可认为它是一个文件存储系统，用来存储元数据信息，同时提供分布式锁服务，另外还负责高效、可靠的主机选举服务
  • RangeServer
    是实际对外提供服务的组件单元，负责数据的读取和写入。
    HyperTable设计中，每张表按照主键切分，形成多个Range（类似关系型数据分表），每个Range由一个RangeServer（RangeServer调用DFS Broker进行数据读写）负责管理。
    HyperTable 中通常部署多个RangeServer，每个RangeServer都负责管理部分数据，由Master来负责进行RangeServer的集群管理
  • Master
    元数据管理中心，管理包括表创建，删除或是其他表空间变更在内的所有元数据操作，同时检测RangeServer的工作状态（RangeServer宕机或重启，能自动进行Range的重新分配，从而实现对RangeServer集群的管理和负载均衡）
  • DFS Broker
    底层分布式文件系统的抽象层，用于衔接上层HyperTable和底层文件存储。（解耦底层文件系统的实现）
    所有对文件系统的读写操作，都通过DFS Broker 来完成。目前已经介入Hypertable中的分布式文件系统包括HDFS、MapR、Ceph和KFS等。对于任何文件系统值需要实现一个对应的DFS Broker，就可以将其快速接入到整个Hypertable系统中。

 3.2.2 算法实现

Hyperspace是整个Hypertalbe中最为核心的部分之一。基于对底层BDB的封装，通过对Paxos算法的实现，Hyperspace很好地保证了Hypertable中元数据的分布式一致性。以下介绍Hyperspace是如何实现分布式数据一致性的。

• • Active Server
    Hyperspace通常以服务器集群的形式部署，一般5~11台服务器，运行过程中，选举一个作为Active Server，其余服务器则是Standby Server （standby备用的），Active Server和Standby Server之间会进行数据和状态的实时同步。
    只有Active Hyperspace 才能真正对外提供服务。
    
    
  • 事务请求处理
    在Hyperspace集群中，还有一个非常重要的组件，BDB。BDB服务也采用集群部署，也存在Master的角色，是Hyperspace底层实现分布式一致性的精华所在。
    Hyperspace对外提供服务时，任何对于元数据的操作，Master模块都会讲其对应的事务请求发送给Hypersapce服务器。接收到请求后，Hyperspace服务器会向BDB集群中的Master服务器发起实务操作。BDB服务器在接收到该事务请求后，会在集群内发起一轮事务请求投票流程，一旦BDB集群内过半服务器成功应用了该事务操作，就会反馈Hyperspace服务器更新已成功，再由Hyperspace响应Master模块。
    
    
  • Active Hyperspace 选举
    当前Active Hyperspace服务器出现故障，集群中剩余的服务器会自动重新选举新的Active Hyperspace，这一过程称为Hyperspace集群的Active选举。
    服务器上事务日志更新时间越新，那么这台服务器被选举的可能性越大，因为只有这样，才能避免集群中数据不一致情况的发生。选举完成后，余下所有服务器就需要和Active Hyperspace服务器进行数据同步，即所有Hyperspace服务器对应的BDB数据库都需要和Master BDB保持一致。
    
    可以看出，需要Hyperspace集群中一半机器正常运行，才能使整个集群能够正常对外提供服务。只有Active Hyperspace才能接受外部请求，并且交给BDB事务来保证一致性。这样就能保证在存在大量并发操作的情况下下，依然能够确保数据的一致性和系统的可靠性。