支付宝代志远：HBase系统故障恢复的优化实践分享

非常高兴来到这个平台能和大家一起分享我们自己所做过技术上的研究和优化。刚才听过各位架构师和经理的演讲，大部分提到了是来自离线方面的计算和存储，我们公司的业务价值最直接的体现其实来自于在线方面，我们海量数据它的存储和计算能力，如果能够体现在在线平台当中，将会给公司业务价值带来非常大的提升。

在Hadoop的体系当中，支持实时的一条线，HBase，支持海量数据库初衷的时候，设计为了设计万一级实时数据库，HBase这个东西经过这几年的发展，已经逐渐成为现在业界当中主要的实时数据库，分布式数据库，像我们公司一样做一些系统，直接上HBase等系统，考虑到HBase它的先进架构，能够帮助我们完成现在很多的海量数据的存储在线随机读写高性能的访问和存储。像HBase这种当前发展试图正使劲得系统，Hadoop作为技术体系在每一个阶段，数据大小阶段有各种不同的问题，从几十台到几百台，到上万台，每个阶段碰到一些问题，从几台到上百台，包括数据量的增长，都会碰到这样的问题，我们今天的分享主要介绍HBase在支付宝的系统当中的故障恢复，这方面我们所做的优化实践。

在HBase的系统当中，体现它的可用性有几个风险。第一个是HBase本身在底层依赖的HDFS，加载了唯一一块数据，单台机器保证一致性，HDFS保持了冗余。第二点，恢复过程当中，Failover过程非常复杂，这个时间消耗越长，作为在线系统，这种时间越长可能会影响到在线访问用户体验。第三点它依赖的HDFS，HBase作为在线数据库依赖HDFS有故障的，经过几小时恢复提供生产业务，对业务方没有直接感受，作为在线系统如果挂掉，我们经过近小时恢复恐怕直接来自于支付宝外部的用户投诉支付宝了。HBase目前它自己的监控体系尚不完善，目前的监控力度非常得粗，只能监控到单台的Region Server的情况，看不到当前用户表有多少读写比例，看不到当前服务结点写作量多少，读出量多少。

今天演讲主题大纲是这样几块内容，支付宝这边消费记录这个项目作为一个背景，切入到所做的优化过程。第二个，提到Region Server恢复过程中有哪些关键流程。第三个，优化架构怎么样。第四对监控方面做了哪些共享？

支付宝消费记录在2011年规划上线，选择HBase的版本0.90X版本，开始出现了0.92、0.94、0.96，每个版本推出了自己不同的特性，作为稳定的版本来说0.90X系列，初中选择了0.090X相对稳定的版本，我们目前计划当中消费记录这个项目还可以打算使用HBase0.92，它的新的特性Coprocessors。我们支付宝消费记录这张表，数据量非常庞大，保留了所有用户使用支付宝的记录，这张表具有数百亿条，存储空间不算在HDFS的冗余，有近百T还是经过压缩之后，如果不压缩存储空间是非常可怕的，我们索引表就已经达到数千亿条，这恐怕也是业内很难碰到的大表，这种是真正意义上的大表。

到目前来说，支付宝业务随着电子支付这块行业的高速膨胀，它的业务增长量非常大增长速度非常得高，增长速度直接体现在整个系统存储，每年翻番的增长量增加存储，我们原有的系统很难支持海量数据的增长，因为拓展能力没有办法非常动态自主进行扩张，我们HBase恰恰满足了这种情况。当我们在回忆支付宝查询过程当中查询记录都是时间段的查询，时间的特性可以看出来，我们时间为排序的都是业务的要求，我们作为在线用户查询，想要自己的消费记录，肯定要有一点响应非常高，肯定不是离线，几秒钟，几分钟之后查出来，对用户来说这种要求是不可接受的。我们作为在线数据必须满足高效的响应。

在HBase替掉之前的解决方案选择了MySQL数据方案，需要非常多的人为分库分表。分库过程中销量磁盘的IO、网络各方面的硬件的资源，这对于在线数据访问来说就是一种冲击，资源的消耗必然会延时用户正常需求。那么不是很适合我们当前的所需要的分布式数据库。第二个特点，我们HBase当前的水平拓展能力非常强，HBase底层以来是Hadoop，Hadoop现行拓展能力大家很清楚，很多人在这方面钻研很久，使用很长时间，现行拓展能力反映在HBase这一层，HBase上层不作为数据存储，底层依赖HDFS，作为数据存储现行拓展。而且HBase当前在建表过程当中支持预先分区分表，可以提前玻璃做好一些负载均衡的事情，HBase现行拓展能力强，吞吐率也非常好。最重要一点，按照时间的排序，这种排序基于了HBase的特性，我们在查询过程当中扫描一段数据，经过排序的连续数据。

我们应用了HBase之后，我们这边的数据量增长大概是已经成长到了5万个Region。我们Rowkey设计，满足它的用户需求是字典排序，只查自己的数据，Userdi  0开头，交易类型再补为0，第二个交易时间最后是交易号，我们选择基于最基础版本HBase0.9、0.1，中间打破了非常多的重要的，我们也碰到其他问题，今天重点只介绍在故障这块的问题，没有经过优化之前，HBase每次响应达到秒级，经过优化之后，他们每次请求响应在20毫秒，我们正常用户都可以接受的实时请求。

刚才大纲当中提到了Region Server在恢复过程当中有几个流程。这个流程很复杂，流程非常非常多，以当前的系统规模，它凸显出来的问题，这几个流程是影响到它的恢复速度的关键流程。等待时间周期非常长，为什么说周期比较长，原因因为我们现在的机器发展速度非常得快，每台机器从两个G到8个G，96G，140多G的大层次的机器，Java语言实现了系统当中大内存管理本身存在问题，除非革新这门语言，否则别无他求。如果说我们在设计的参数不合理，可能会导致一个问题，我们有可能会发生这台服务器停止，发生这么一次情况就非常可，几十G的内存这个过程需要几十秒甚至上分钟，通常情况下，我们会设置到3分钟，意味着，我们为了避免出现这种问题，同时引入新的问题，我们宕机之后恢复等待时间需要三分钟。第二个关键流程当中，当它感知到已经挂掉了，在线数据库协助WL数据重新做到存储当中去，以保证实时更新是同步，否则这个数据库肯定要丢出去，重做数据过程当中，会有一个过程，Split Hlog，跟当前数据量有关系，Edit Log数据又比较多，大家在业余时间可以进行测试，数据不以我们为准，以当前数据系统大小为准。

第三个关键流程，重做完数据之后，这部分重新上线，上线之前进行数据进行二次扫描，告诉系统说，我的Region怎么加入到Region Server当中去，扫描也存在问题，问题可能引发到两分钟到6分钟，这也跟当前系统数据有关。第四部分，这个过程称之为再次上线的过程，这个再次上线，上线时间跟当前这台机器的Region上线有关系。我们支付宝面对消费记录查询，用户查不出来数据，15分钟之后才能查到，这是非常可怕的面临在线的事情。

针对我们在Region Server这一层关键流程当中，我们做了一些优化。这个优化正是提到关键流程第一点，在判断宕机超市的情况下，不强依赖于Zookeeper，我们又启动了监控进程，叫Mirror Process，每一台，Region Server当中都会起到PID存不存在，这种检查并非完全可靠，当检查PID不存在，我们有理由认为已经挂掉了，要进行可靠检查，通常DBA在线判断数据库是否可用，通常会用PIng连续服务端口，这就弥补了系动中的调用命令不可靠的事情。

最后当我们发现服务端口不可用，有理由认为当前进程已经死掉了，死掉了之后，我们按照现有逻辑删除结点，这三分钟的时间就完全省略掉。

这是我们在优化ZK宕机启动流程。首先，Region Server会启动自身自己服务，会向ZK注册，注册自己专有结点，监控自己的进程如果是就会发PID，如果不是就会直接进入下一步。

优化强依赖Zookeeper的宕机超时判断监控进程的启动流程，我发现当前我的Region Server已经启动了，我会主动向我的Region Server拉动它，保证了PD的唯一性。为什么不采用在系统级的PS一下，检查一它的进行字符匹配，其实我们认为这不是很可靠，假如说程序当中判断失误，我们有可能会检查到原本不属于进程该检查，会造成监控的失误，误删除的现象存在，我们启动了自己认为可靠的程序进行监控。

同时我们认为除了自己本机Region Server会宕掉之后，还存在这台机器完全宕机的风险，完全宕机如果Region Server所在的机器，所启动的监控进程它只监控自己当前的Region Server，就会面临这样一个问题，如果整台机器全部管掉了，我们监控其实失效了，肯定还是要回到原来的起点当中等待ZK的超市，除了本机监控之外还应该依赖于其他当中相互覆盖的监控方式，比如说，相邻两个结点，除了只监控自己本机PID是否存在和自己端口是否存在，我还可以检查进程相邻第二台机器B的服务端口是否存在，这就做到了看似非常复杂的网络结构的完整监控模式。目前，我们将思路已经提了专利，我们也提到了社区，我们跟社区的思路不是特别一样社区有另外考虑，在5075社区考虑是否用Java的方式来做，大同小异，跟我们做的优化目的是一样，总之为了减少等待时间。

我们当前解决方案只能说检查当前机器的服务是否存在，不能检查我们当前机器它Region Server内部的问题，比方说这台机器当中发生的异常状况，死锁，这是内核的问题，Region Server更内层的东西进行加以优化和修订。所以说我们也是有利有弊的过程，不是完全像第二种说到的情况。关于Region Server宕机恢复第二流程，就是重做HLog的时间，0.9X系列目前单线程，如果设置256兆，如果写读量非常大，周期上线是32Hlog，这32和250乘起来，Java处理速度，能有50到每秒不错了，实际上达不到这种速度，在现有机械盘当中缓冲区和内存交互速度是30兆每秒，可以算一下256乘以32除以30，很可观的数字，得到了现有系统当中业务量重做Hlog的时间，串行处理必然降低了速度，在社区的0.92意识到这个问题，Hlog分发到每台Region Server都会写入最终数据块的服务区当中，这样的话，利用了每个台机器服务能力，我们每台机器只做一个Hlog的恢复，256除以30，速度可以看到得到质的提升，就是并行的方案。有一定请各位注意，0.92并行Hlog可能出现丢数据的现象，0.94代码并行做过一些修复，我们初期用了1364版本，但是在0.94系列里面做过同步的代码，保证至少测试当中都是能过的，目前应用系统当中还没有发现丢数据的现象。

还有一个问题扫描原数据的问题，如果Rewion越多数据肯定是越多的，现有问题也存在一系列的问题，RPC的问题，特定场景才会发现的，如果发生这个问题，可能延迟几分钟时间，如果没有这个问题，这部分所带来的消耗也并不是太长，主要会集中在第二步当中，第一步肯定要加以防范，这个参数其实非常简单。第二步也是参数上的优化，大家可以实验。

我们宕机服务Region恢复的优化，我们解决方案采用并行方式，优于单线程串行的时间，直接使用了HBase初期启动，速度上大大提升，这是我们最终的效果图。这个效果图在第一个阶段当中，我们将缩短零秒并行10秒左右，其实15分钟到20分钟的优化上线的时间。这是我们效果最终对比，时间可以看得出来，优化后比优化前速度有质的提升，单位是一千到900，这个是秒。最重要的一点，我们在HDFS做了HA的优化，现在社区提出非常多的HA方案，他们都是作为为了解决HDFS单点问题所存在的，现在方案写到本地文件系统和其他东西当中，目前所做的工作至今是尚不成熟的，这部分有的是功能上满足不了。我们在新的社区代码当中发现了，保证在发现机器宕机之后像Node的关系，我们来源于社区还会还自于社区，依赖于社区已有的解决方案，我们加以做了整合和自己的二次研发。

我们所做的目标得到都是清楚的，首先是自动热切目标就是HBase的不定期服务，我们整盘架构图，我们Name  Node之间的优化，处理逻辑不一样，我们利用分布式的方式加一个Node，如果想当前状态没有切过去，就会向客户端抛出异常，我是这样的状态你不可以操作，保证了两台机器数据不会被干扰的。另外一点，Name Node关系是怎么样的，同时会显数据，写的过程当中除了这个数据结构之外还有另一个结构，删除了哪些文件，主要操作Name Node上来进行。

监控的环节作为在线系统和离线系统是非常重要的环节。如果没有监控，监控相当于是雷达，只有有了雷达才可以发现当前系统当中有什么问题做诊断，对它判断当前是否负载过重等现象的存在，这样才有线上的运维，对症下药，否则系统像无头苍蝇一样没法做工作正常安排。我们看到当前读写比例有多少，我们写了DPS的展现，单个Region Server，WPS、KPS，还有重要一点，当前Region Server输出量和写入量分别是多少。

最后，现在是整集群的判断，集群当中不可能上一张表，可能会上多张索引表，整个集群为了利用率的上升，我们会考虑一个集群上多张表，多张表现有的展现方式看不到KPS、WPS分别是多少，我们可以告诉监控，表一WPS、KPS多少，这也可以解决在运维当中到底解决问题的。这部分是集群当中看到的信息，一台Region Server，KPS，WPS当前读取量和输出量。整体所做的事情为了作为在线系统提高它的可用性，它会走向在线数据库的平台，我们研究和付出能给你们今后使用带来一定的帮助。谢谢大家。