Paxos的工程实践之Hypertable。

        Hypertable是一个使用C++ 语言开发的开源、高性能、可伸缩的数据库，其以Google的BigTable相关论文为基础指导，采用与HBase非常相似的分布式模型，其目的是要构建一个针对分布式海量数据的高并发数据库。

概述

        目前Hypertable只支持最基本的增、删、改、查功能，对于事务处理和关联查询等关系型数据库的高级特性都尚未支持。同时，就少量数据记录的查询性能和吞吐量而言，Hypertable可能也不如传统的关系型数据库。和传统关系型数据库相比，Hypertable最大的优势在于以下几点。

• 支持对大量并发请求的处理。
• 支持对海量数据的管理。
• 扩展性良好，在保证可用性的前提下，能够通过随意添加集群中的机器来实现水平扩容。
• 可用性极高，具有非常好的容错性，任何节点的失败，既不会造成系统瘫痪也不会影响书v就的完整性。

        Hypertable的整体架构如下图所示。

        Hypertable的核心组件包括Hyperspace、RangeServer、Master和DFS Broker四部分。其中Hyperspace是Hypertable中最重要的组件之一，其提供了对分布式锁服务的支持以及对元数据的管理，是保证Hypertable数据一致性的核心。Hyperspace类似于Google BigTable 系统中的 Chubby，在这里我们可以认为他是一个文件存储系统，主要用来存储一些元数据信息，同时提供分布式锁服务，另外还负责提供高效、可靠的主机选举服务。

         RangeServer 是实际对外提供服务的组件单元，负责数据的读取和写入。在Hypertable的设计中，对每一张表都按照主键进行切分，形成多个Range（类似于关系型数据库中的分表）负责管理。在Hypetable中，通常会部署多个RangeServer，每个RangeServer都负责管理部分数据，由Master来负责进行RangeServer的集群管理。

        Master是元数据管理中心，管理包括创建表、删除表或是其他表空间变更在内的所有元数据操作，同时负责检测RangeServer的工作状态，一旦某一个RangeServer宕机或是重启，能够自动进行Range的重新分配，从而实现对RangeServer集群的管理和负载均衡。

        DFS Broker则是底层分布式文件系统的抽象层，用于衔接上层Hypertable和底层文件存储。所有对文件系统的读写操作，都是通过DFS Broker来完成的。目前已经可以接入Hypertable中分布系统包括HDFS、MapR、Ceph和KFS等，针对任何其他新的文件系统，只需要实现一个对应的DFS Broker，就可以将其快速接入到整个Hypetable系统中。

算法实现

        从上面讲解中我们了解到，Hyperspace是整个Hypertable中最为核心的部分之一。基于对底层BDB的封装，通过对Paxos算法的实现，Hyperspace能够很好的保证Hypertable中元数据的分布式一致性。接下来我们就看看Hyperspace是如何实现分布式数据一致性的。

Active Server

        Hyperspace通常以一个服务器集群的形式部署，一般由5~11台服务器组成，在运行过程中，会从集群中选举产生一个服务器作为Active Server，其余的服务器则是Standby Server，同时，Active Server 和 Standby Server 之间会进行数据和状态的实时同步。

        在Hypertable启动初始化阶段，Master模块会连接上Hyperspace集群中的任意一台服务器，如果这台Hyperspace服务器恰好处于Active状态，那么便完成了初始化连接；如果连接上的Hyperspace服务器恰好处于Active状态，那么便完成了初始化连接；如果连接上的Hyperspace服务器处于Standby状态，那么该Hyperspace服务器会在此次连接创建后，将当前处于Active状态的Hyperspace服务器地址发送给Master模块，Master模块会重新与该Active Hyperspace服务器建立连接，并且之后对Hyperspace的所有操作请求都会发送给这个Hyperspace服务器。换句话说，只有Active Hyperspace才能真正的对外提供服务。

事务请求处理

        在Hyperspace集群中，还有一个非常重要的组件，就是BDB。BDB服务也是采用集群部署的，也存在Master的角色，是Hyperspace底层实现分布式数据一致性的精华所在。在Hyperspace对外提供服务时，任何对于元数据的操作，Master模块都会将其对应的事务请求发送给Hyperspace服务器。在接收到该事务请求后，Hyperspace服务器就会向BDB集群中的Master服务器发起事务操作。BDB服务器在接收到该事务请求后，会在集群内部发起一轮事务请求投票流程，一旦BDB集群内部过半的服务器成功应用了该事务操作，就会反馈Hyperspace服务器更新已经成功，再由Hyperspace响应上层的Master模块。

        举个例子来说，假设有一个由5台服务器组成的Hyperspace集群，其Active Hyperspace在处理一个建表请求时，需要获得至少3台BDB服务器的同意才能够完成写入。虽然这样的事务更新策略显然会严重影响其对写操作的响应速度，但由于其存入的元数据更新并不特别频繁，因此对写性能的影响还在可接受的范围内——毕竟数据的可靠一致才是最重要的。

Active Hyperspace 选举

        当某台处于Active状态的Hyperspace服务器出现故障时，集群中剩余的服务器会自动重新选举出新的Active Hyperspace，这一过程称为Hyperspace集群的Active选举。Active 选举过程的核心逻辑就是根据所有服务器上事务日志的更新时间来确定哪个服务器的数据最新——事务日志更新时间越新，那么这台服务器被选举为Active Hyperspace的可能性就越大，因为只有这样，才能避免集群中数据不一致情况的发生。完成Active Hyperspace选举之后，余下所有的服务器就需要和Active Hyperspace服务器进行数据同步，即所有Hyperspace服务器对应的BDB数据库的数据都需要和Master BDB 保持一致。

        从上面的讲解中我们可以看出，在整个Hyperspace的设计中，为了使整个集群能够正常的对外提供服务，那么就必须要求Hyperspace集群中至少需要有超过一般的机器能够正常运行。另外，在Hyperspace集群正常对外提供服务的过程中，只有Active Hyperspace才能接受来自外部的请求，并且交由底层的BDB事务来保证一致性——这样就能够保证在存在大量并发操作的情况下，依然能够保证数据的一致性和系统的可靠性。