万亿级日访问量下的京东HBase平台异地多活实践

栏目: IT技术 · 发布时间: 4年前

万亿级日访问量下的京东HBase平台异地多活实践

JDHBase在京东集团作为线上kv存储,承担了大量在线业务,11.11、6.18 均经历了每天万亿级读写访问请求,目前规模达到7000+节点,存储容量达到了90PB。场景涉及商品订单、评价、用户画像、个性推荐、金融风控、物流、监控等700+业务。

万亿级日访问量下的京东HBase平台异地多活实践

JDHBase上承载了大量核心业务,遍布全球多个Data Center。为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地多活系统。本文主要介绍我们在异地多活系统的实践。

HBase Replication原理

HBase是典型的LSM(Log-Structured Merge-Tree)结构数据库,服务端响应客户端写请求过程中,会写入Memstore(内存)中和顺序的写入WAL日志(HDFS文件)中,WAL日志确保数据真正写入磁盘,从而在节点故障时恢复未被持久化的内存数据。

万亿级日访问量下的京东HBase平台异地多活实践

HBase的Replication是基于WAL日志文件的。在主集群中的每个RegionServer上,由ReplicationSource线程来负责推送数据,在备集群的RegionServer上由ReplicationSink线程负责接收数据。

ReplicationSource不断读取WAL日志文件的数据,根据Replication的配置做一些过滤,然后通过replicateWALEntry的rpc调用来发送给备集群的RegionServer,备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作,以batch的形式写入到备集群中。

万亿级日访问量下的京东HBase平台异地多活实践

因为是后台线程异步的读取WAL并复制到备集群,所以这种Replication方式叫做异步Replication,正常情况下备集群收到最新写入数据的延迟在秒级别。

JDHBase异地多活架构

JDHBase服务端与客户端交互主要包含三个组件:Client、JDHBase集群、Fox Manager。

Client启动时首先向Fox Manager端汇报用户信息,Fox Manager进行用户认证后,返回集群连接信息,Clinet收到集群连接信息后,创建集群连接HConnection,从而与Fox Manager指定的集群进行数据交互。

万亿级日访问量下的京东HBase平台异地多活实践

1、Fox Manager配置中心

负责维护用户及JDHBase集群信息,为用户提供配置服务,同时管理员做配置管理。

万亿级日访问量下的京东HBase平台异地多活实践

  • Policy Server:分布式无状态的服务节点,响应外部请求。数据持久化目前为可选的 Mysql 或Zookeeper。Policy Server中还包含了一个可选的Rule Engine插件,用于根据规则和集群的状态,自动修改用户配置,如集群连接地址信息、客户端参数等。

  • Service Center:Admin配置中心的UI界面,供管理员使用。

  • VIP Load Balance:对外将一组Policy Server提供统一访问地址并提供负载均衡能力。

2、JDHBase Cluster

JDHBase Cluster提供高吞吐的在线OLTP能力。我们对可靠性要求比较高的业务做了异地多活备份。

万亿级日访问量下的京东HBase平台异地多活实践

  • Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。

  • Standby Cluster:异常情况下,全部或部分业务会切换到此集群运行。在此集群上运行的业务数据也会异步备份到Active Cluster上。

两个集群间通过Replication备份数据,根据集群ID防止数据回环。主备集群间数据达到最终一致性。

实际生产中,我们根据两个建群间的Replication,构建了多集群间的Replication拓扑,使得集群互为主备。一个集群上会承载多个业务,不同的业务的备份也会散落在不同的集群上,形成多集群间的拓扑结构。 

万亿级日访问量下的京东HBase平台异地多活实践

3、Client

万亿级日访问量下的京东HBase平台异地多活实践

Client负责拉取Fox Manager端配置信息,根据配置信息为用户提供接口,与主集群或者备集群进行数据交互,同时将客户端状态上报给Fox Manager端。

集群切换

HBase在读写数据时,需要先经过数据路由,找到数据所在(或应当所在)的节点位置,然后与节点进行数据交互。简单来说包含以下三步:

  • client端访问HBase集群的zookeeper地址,通过访问znode获取集群META表所在位置。

  • 访问META表所在节点,查询META表获取数据分片(Region)信息。同时缓存META表数据。

  • 根据数据分片信息访问数据所在节点,进行数据交互。

万亿级日访问量下的京东HBase平台异地多活实践

JDHBase在client端数据路由前,多加了一步访问Fox Manager的步骤,这一步骤主要有两个作用:一是进行用户认证;二是获取用户集群信息;三是获取客户端参数。

万亿级日访问量下的京东HBase平台异地多活实践

对集群切换来说,重要的是用户集群信息和客户端参数。Client端拿到具体的集群信息(zk地址),然后进行正常的数据路由,这样业务的client端不需要关心访问哪个集群,Fox Manager端只要保证为client提供的路由集群可用即可。

Fox Manager还会为Client提供一些特殊配置参数,例如重试、超时等,这些配置参数依据两个维度:集群特性和业务属性。这些参数的设置需要结合业务场景和要求长期观察,属于专家经验;也包括一些极端情况下的临时参数。

我们也在client sdk中添加了metrics,用于评估client端视角的服务可用性。基于metrics,我们为一些极度敏感的业务开启客户端切换,当客户端可用率降低生效。

在client sdk中添加的metrics,用于评估client端视角的服务可用性。Client启动后会与Fox Manager建立心跳,一方面通过心跳上报客户端状态以及部分metrics指标到Fox Manager,这些数据能够帮助我们分析服务运行状态;另一方面Client端能够获取Fox Manager端对Client的配置更新。这样,当管理员在Fox Manager为Client更新了集群配置,Client端能够及时感知并重建数据路由。

另外,我们也做了对Client的精准控制。一方面可以使业务的部分Client实例路由到不同集群,另一方面可以作为一些极端情况下单个Client实例强制更新集群信息并切换的备用手段。

万亿级日访问量下的京东HBase平台异地多活实践

自动切换

在有了主备集群切换之后,我们仍面临时效性的问题。故障情况下,我们从监控到异常到报警,到人工介入,最快仍需要分钟级恢复服务可用性。这对一些线上业务来说仍然不可接受。

为了提高服务SLA质量,我们开发了基于策略的主备集群自动切换。可以根据策略在服务异常时,触发切换,将故障恢复时间控制到秒级。

万亿级日访问量下的京东HBase平台异地多活实践

首先我们在HMaster上做了状态检测插件,用于收集一些影响服务可用性的指标信息,heartbeat的方式上报到Fox Manager的PolicyServer中。

PolicyServer 是对外提供查询和修改策略的服务,它所有策略数据会存储在MySQL中。可以通过加节点的方式动态扩展形成一个服务集群,避免单点问题。

PolicyServer中的Rule Engine负责根据HMaster上报的集群状态的指标信息推测执行切换策略。服务可用性对不同指标的敏感度不同,本质上Rule Engine在多个时间窗口上对不同的指标或多个指标的组合执行策略。

Rule Engine不需要高吞吐,重要的是保障可用性,因此基于Raft做了高可用。Active的Rule Engine节点挂掉后,立即会被另外一台节点接管。

动态参数&自动调速

Replication本身是通过RegionServer发送到备机群,而RegionServer本身有大量线程用于客户端请求,Replication Source的线程和负载很难与客户端请求相匹配,在大量写或者有热点的情况下,很容易出现Replication积压。

这个问题我们可以通过调节Replication 参数来缓解这种积压的情况。HBase本身基于观察者模式支持动态参数,更新RegionServer节点参数后,执行update config动作即可生效。我们扩展了动态参数,将Replication的一些参数做成了动态生效的。当Replication积压比较严重时,可以在集群上或者在响应的分组、节点调整参数,不需要重启节点。

虽然Replication动态参数不需要重启RegionServer,但是上线还是比较麻烦的,需要人工参与,并且写热点积压不可预测,依然很难做到Replication平稳顺滑。因此我们进一步在Replication Source端根据当前节点积压的情况(几个阈值),在一定范围内自动调节Replication参数,从而达到自动调速的功能。目前参数自动调节范围在基础参数值的1-2倍之间。

跨机房异地数据中心的之间的带宽是有限的,在业务流量高峰期不能将有限的网络资源用于同步数据。因此在Fox Manager端我们也做了对集群的相应控制,分时段调整Replication速度。

串行Repication

主备集群间的Replication本身是异步的,正常情况下两个集群可以达到最终一致性。但是某些情况下并不能完全保证。

在HBase的Replication中,通过读取每个RegionServer中的WAL将数据变化推到备集群。HBase在zookeeper中维护了一个对WAL文件的队列,因此可以按创建时间顺序读取这些WAL文件。

但是当Region发生移动或者RegionServer故障转移,那么Region所在的新的RegionServer上的WAL日志可能会先于老的WAL日志推送到备集群,这种情况下备集群上的数据写入顺序与主集群是不一致的。更极端的情况,如果这种顺序不一致发生在同一条数据上,那么可能会导致数据永久不一致。

举个例子,首先在主集群中执行Put,然后执行Delete来删除它,但是Delete操作先replication到了备集群,而备集群如果在接收Put之前进行了major compact,major compact过程会删除掉delete marker,随后备集群接收到了这条put,那么这条put在备集群上将没有机会再delete,将会一直存在。

解决这个问题需要保证任何情况下,Replciation的顺序与主集群的mutation顺序是一致的,即串行Replication(Serial Replication, backport form v2.1)。例如当Region发生移动从RegionServer1移动到了RegionServer2,那么RegionServer2应当等待RegionServer1将此region的所有数据推送完,再进行推送。

串行Replciation使用Barrier和lastPushedSequenceId来解决这个问题。每当Region发生Open时,都会在meta表中记录一个新的Barrier,这个Barrier为当前Region的最大SequenceId + 1。lastPushedSequenceId为当前region推送到备集群的SequenceId,在Replciation的过程中,每个batch成功,会在Zookeeper中记录最大的SequenceId,即lastPushedSequenceId。

万亿级日访问量下的京东HBase平台异地多活实践

如图所示,一个Region从RegionServer1移动到RegionServer2,又到RegionServer3,发生多次Region Open,记录了多个Barrier,构成多个Range:[ Barrier(n) , Barrier(n+1) )。期间有多个mutation操作记录的SequenceId:s1、s2、s3、……

RegionServer在进行数据Replication前,首先检查lastPushedSequenceId 是否大于自己区间的起始Barrier。例如上图中RegionServer3会首先检查,当lastPushedSequenceId >= Barrier1 – 1时才会进行Replication,而此lastPushedSequenceId = s2,则说明lastPushedSequenceId所在Range的RegionServer2正在进行Replication,那么RegionServer3需要等待。这样就保证了数据抵达备集群的顺序与主集群的写入顺序是相同的。

总结与展望

JDHBase在不断吸收业界异地灾备经验的同时,也经过一系列的实践和演进,目前SLA已经能够达到99.98%,从毫无异地容灾措施到完善的监控、告警、切换、一致性保障机制,为业务提供稳定可靠的存储服务。

同时随着业务的增多和数据量的增大,集群规模也越来越大,仍面临一些挑战,未来我们在异地灾备方面将会着力在同步的Replication、去zookeeper依赖、客户端视角自动切换、降低数据冗余等方面继续提升可靠性及稳定性。

> > > >

参考资料

  • https://hbase.apache.org/book.html#_cluster_replication

  • https://mapr.com/blog/in-depth-look-hbase-architecture/

  • https://issues.apache.org/jira/browse/HBASE-20360

  • https://issues.apache.org/jira/browse/HBASE-20046

作者丨架构师臧勇真

来源丨京东零售技术(ID:jd-sys)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱: editor@dbaplus.cn

> > > >

活动推荐

2020年4月17日,北京,Gdevops全球敏捷运维峰会将 开启年度首站! 重点围绕数据库、智慧运维、Fintech金融科技领域,携手阿里、腾讯、蚂蚁金服、中国银行、平安银行、中邮消费金融、建设银行、农业银行、民生银行、中国联通大数据、浙江移动、新炬网络等技术代表,展望云时代下数据库发展趋势、破解运维转型困局。

万亿级日访问量下的京东HBase平台异地多活实践


以上所述就是小编给大家介绍的《万亿级日访问量下的京东HBase平台异地多活实践》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Effective Java

Effective Java

Joshua Bloch / Addison-Wesley Professional / 2018-1-6 / USD 54.99

The Definitive Guide to Java Platform Best Practices—Updated for Java 9 Java has changed dramatically since the previous edition of Effective Java was published shortly after the release of Jav......一起来看看 《Effective Java》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具