转载

Apache HBase高可用性的新阶段

Apache HBase是一个面向线上服务的数据库，其原生支持Hadoop的特性，使其成为那些基于Hadoop的扩展性和灵活性进行数据处理的应用显而易见的选择。

在Hortonworks数据平台（HDP http://zh.hortonworks.com/hdp/） 2.2中，HBase的高可用性得到了长足的发展，能够保证其上运行应用的正常运行时间达到99.99%。

本文将回顾过去12个月的开发历程，展示开发人员如何改进HBase的高可用性，并讨论未来的改进计划。

HBase高可用性的历史观点

高可用性(HA)是任何数据库的关键特性，也是任何核心业务应用的先决条件。

以前，HBase使用两种策略来保障数据的可用性：

第一，HBase将数据自动分区，并将各个分区发布到不同的节点上去。某个节点下线或宕机只会影响该节点上的数据，其他节点上的数据不会受到影响。

第二，所有存储在HBase上的数据实际上都被存储在HDFS上，数据被备份成3份，分布在不同的节点上，并且集群中任何节点都可以使用这些数据。

这使得HBase可以自动将失败节点上托管的数据重新分配给正常的节点，从而保证了数据的高可用性。

如果综合利用这些固有的HA特性，并结合Hadoop最佳实践，使得基于HBase应用的高可用性完全有可能达到99.9%，即每年总宕机时间低于9小时。

这适用于大多数应用，而对于系统核心应用来说，需要更高的可用性保障。

更好的高可用性需求

我们正处于大数据应用转向Hadoop平台再造的早期阶段。 Hadoop的普及率和影响力与日俱增，已成为强调系统扩展性或者数据处理灵活性应用的不二之选。

对于那些想从Hadoop无处不在、进展迅速的创新中受益的线上应用来说，HBase作为Hadoop生态中的一员，自然成为首选的数据库。

当我们与一些希望将关键业务迁移到HBase上的客户交流时，我们经常收到如下反馈，客户需要HBase提供数据一致性，但是却无法容忍哪怕是很短的宕机恢复时间。为了使Hadoop能够支撑在线应用的关键业务，HBase的高可用性特性需要进行大幅度的改进。

Hortonworks与HBase社区通力合作，通过引入时间轴一致区域副本技术（也称HBase读高可用性，相关内容参考HBASE－10070【https://issues.apache.org/jira/browse/HBASE-10070】），极大的提高了HBase的高可用性。

从上层看，这个新的HA特性在遍布HBase集群的主区域副本和备区域副本中维持相同数据的多个备份。利用HBase读高可用性，如果一个RegionServer失败后，用户仍然可以从其他RegionServer上读取失败节点上的数据。

也就是说，在系统自动恢复期间，用户只是失去了该节点的写可用性，但仍然可以读取该节点的数据。对于那些需要持续可读并且保持读一致性的应用来说，HBase的读高可用性特性是一个理想的选择。

结合最佳实践，如使用双副本和机架感知，HBase读高可用性可以使得那些依赖HBase的关键业务应用的可用性达到99.99%。

Apache HBase高可用性的新阶段

什么是时间轴一致性？

从好的一面看，这个方式使得保证数据一致性的实现非常简单，只有一个所有者的策略意味着不会出现脑裂，不会出现最后一次写有效（last-write-wins）的情况，并且让计数器这类重要功能的实现变得快速和简单。

从不好的一面看，如果一个RegionServer宕机了，这个RegionServer持有的所有键值范围都将离线，直到数据恢复过程完成为止。

在HBase 0.96中，这个恢复过程已经优化到一分钟以内，不过，我们还是牺牲了一些可用性来保证数据的高度一致性。根据CAP理论，我们必须折中考虑一致性和可用性，并且还没有一个完美的系统，可以一直兼顾一致性和可用性。

很多现代数据库系统试图通过实现纯粹的AP模型来优化可用性，即放弃一致性以优化可用性。放弃一致性使得这类数据库的用户不得不直面分布式系统中的一些复杂的议题。很多时候，最终一致性数据库的用户更像是数据库开发人员，而不仅仅是数据库使用者。

实际上，网络分区问题并不是一直都存在，所有，没有必要为了防止偶尔发生的故障而在任何时候都牺牲一致性。如果对这方面的讨论和时间轴一致性的相关内容感兴趣，可以读一下Daniel Abadi的博客【http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html】。

HBase的读高可用性实现了一个时间轴一致性的系统，该系统为开发人员提供在查询阶段选择使用严格的一致性策略还是宽松的一致性策略的功能。

使用HBase的读高可用性：