JDHBase在京东集团作为线上kv存储,承担了大量在线业务,11.11、6.18 均经历了每天万亿级读写访问请求,目前规模达到7000+节点,存储容量达到了90PB。场景涉及商品订单、评价、用户画像、个性推荐、金融风控、物流、监控等700+业务。
JDHBase上承载了大量核心业务,遍布全球多个Data Center。为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地多活系统。本文主要介绍我们在异地多活系统的实践。
HBase Replication原理
HBase是典型的LSM(Log-Structured Merge-Tree)结构数据库,服务端响应客户端写请求过程中,会写入Memstore(内存)中和顺序的写入WAL日志(HDFS文件)中,WAL日志确保数据真正写入磁盘,从而在节点故障时恢复未被持久化的内存数据。
HBase的Replication是基于WAL日志文件的。在主集群中的每个RegionServer上,由ReplicationSource线程来负责推送数据,在备集群的RegionServer上由ReplicationSink线程负责接收数据。
ReplicationSource不断读取WAL日志文件的数据,根据Replication的配置做一些过滤,然后通过replicateWALEntry的rpc调用来发送给备集群的RegionServer,备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作,以batch的形式写入到备集群中。
因为是后台线程异步的读取WAL并复制到备集群,所以这种Replication方式叫做异步Replication,正常情况下备集群收到最新写入数据的延迟在秒级别。
JDHBase异地多活架构
JDHBase服务端与客户端交互主要包含三个组件:Client、JDHBase集群、Fox Manager。
Client启动时首先向Fox Manager端汇报用户信息,Fox Manager进行用户认证后,返回集群连接信息,Clinet收到集群连接信息后,创建集群连接HConnection,从而与Fox Manager指定的集群进行数据交互。
1、Fox Manager配置中心
负责维护用户及JDHBase集群信息,为用户提供配置服务,同时管理员做配置管理。
-
Policy Server:分布式无状态的服务节点,响应外部请求。数据持久化目前为可选的 Mysql 或Zookeeper。Policy Server中还包含了一个可选的Rule Engine插件,用于根据规则和集群的状态,自动修改用户配置,如集群连接地址信息、客户端参数等。
-
Service Center:Admin配置中心的UI界面,供管理员使用。
-
VIP Load Balance:对外将一组Policy Server提供统一访问地址并提供负载均衡能力。
2、JDHBase Cluster
JDHBase Cluster提供高吞吐的在线OLTP能力。我们对可靠性要求比较高的业务做了异地多活备份。
-
Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。
-
Standby Cluster:异常情况下,全部或部分业务会切换到此集群运行。在此集群上运行的业务数据也会异步备份到Active Cluster上。
两个集群间通过Replication备份数据,根据集群ID防止数据回环。主备集群间数据达到最终一致性。
实际生产中,我们根据两个建群间的Replication,构建了多集群间的Replication拓扑,使得集群互为主备。一个集群上会承载多个业务,不同的业务的备份也会散落在不同的集群上,形成多集群间的拓扑结构。
3、Client
Client负责拉取Fox Manager端配置信息,根据配置信息为用户提供接口,与主集群或者备集群进行数据交互,同时将客户端状态上报给Fox Manager端。
集群切换
HBase在读写数据时,需要先经过数据路由,找到数据所在(或应当所在)的节点位置,然后与节点进行数据交互。简单来说包含以下三步:
-
client端访问HBase集群的zookeeper地址,通过访问znode获取集群META表所在位置。
-
访问META表所在节点,查询META表获取数据分片(Region)信息。同时缓存META表数据。
-
根据数据分片信息访问数据所在节点,进行数据交互。
JDHBase在client端数据路由前,多加了一步访问Fox Manager的步骤,这一步骤主要有两个作用:一是进行用户认证;二是获取用户集群信息;三是获取客户端参数。
对集群切换来说,重要的是用户集群信息和客户端参数。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实例强制更新集群信息并切换的备用手段。
自动切换
在有了主备集群切换之后,我们仍面临时效性的问题。故障情况下,我们从监控到异常到报警,到人工介入,最快仍需要分钟级恢复服务可用性。这对一些线上业务来说仍然不可接受。
为了提高服务SLA质量,我们开发了基于策略的主备集群自动切换。可以根据策略在服务异常时,触发切换,将故障恢复时间控制到秒级。
首先我们在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。
如图所示,一个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平台异地多活实践》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- FreeSky主题访问量统计修复
- 一年,近8w访问量,码云 Star 4k+
- 万亿级日访问量下,Redis 在微博的 9 年优化历程
- 假如有1亿用户的访问量,你的服务器架构是怎样的?
- Go实现网站访问量控制(滑动窗口算法,类似利用Redis List数据结构属性)
- 稳定性相关异地多活
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
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》 这本书的介绍吧!