zoukankan      html  css  js  c++  java
  • HBase——Replication(复制)原理

    前言

    Replication:复制,指的是持续的将同一份数据拷贝到多个地方进行存储,是各种存储系统中常见而又重要的一个概念,

    可以指数据库中主库和从库的复制,也可以指分布式集群中多个集群之间的复制,还可以指分布式系统中多个副本之间的复制。

    它的难点在于数据通常是不断变化的,需要持续的将变化也反映到多个数据拷贝上,并保证这些拷贝是完全一致的。

    通常来说,数据复制到多个拷贝上有如下好处:

    • 多个备份提高了数据的可靠性

    • 通过主从数据库/主备集群之间的复制,来分离OLTP和OLAP请求

    • 提高可用性,即使在单副本挂掉的情况下,依然可以有其他副本来提供读写服务

    • 可扩展,通过增加副本来服务更多的读写请求

    • 跨地域数据中心之间的复制,Client通过读写最近的数据中心来降低请求延迟

    HBase中的Replication指的是主备集群间的复制,用于将主集群的写入记录复制到备集群。HBase目前共支持3种Replication:

    • 异步Replication
    • 串行Replication
    • 同步Replication

    一、HBase架构

    如果想把HBase的Replication搞清楚,首先需要了解下HBase的架构。

    HBase集群是由一组进程组成的,进程按角色分为Master和RegionServer,其中Master负责DDL操作,比如建表、删表,而RegionServer负责DML操作,比如数据的读写操作等。

    从数据视图上讲,HBase中的Table会按Range切分为多个Region,然后由不同的RegionServer来负责对外提供服务。

    RegionServer的内部则主要有BlockCache,MemStore和WAL等几部分组成。

    需要注意的是每个Region的每个Column Family有自己独享的MemStore,但是BlockCache和WAL则是多个Region共享的。

    WAL(Write-ahead logging)是数据库中的常用技术,所有的修改在写入数据库之前都需要持久化到WAL中,从而确保了在出现故障的时候,可以从WAL中回放出已经成功写入的数据。

    二、异步Replication

    HBase中的Replication也是基于WAL的,其在主集群的每个RegionServer进程内部起了一个叫做ReplicationSource的线程来负责Replication,

    同时在备集群的每个RegionServer内部起了一个ReplicationSink的线程来负责接收Replication数据。

    ReplicationSource记录需要同步的WAL队列,然后不断读取WAL中的内容,同时可以根据Replication的配置做一些过滤,比如是否要复制这个表的数据等,

    然后通过replicateWALEntry这个Rpc调用来发送给备集群的RegionServer,备集群的ReplicationSink线程则负责将收到的数据转换为put/delete操作,以batch的形式写入到备集群中。

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

    三、串行Replication

    注意:此功能是HBase 2.1中引入的。增加属性:SERIAL => true

    串行Replication指的是:对于某个Region来说,严格按照主集群的写入顺序复制到备集群,其是一种特殊的Replication。

    同时默认的异步Replication不是串行的,主要原因是Region是可以移动的,比如HBase在进行负载均衡时移动Region。

    假设RegionA首先在RegionServer1上,然后其被移动到了RegionServer2上,由于异步Replication是存在延迟的,

    所以RegionA的最后一部分写入记录还没有完全复制到备集群上。在Region移动到RegionServer2之后,其开始接收新的写入请求,并由RegionServer2来复制到备集群,

    所以在这个时候RegionServer1和RegionServer2会同时向备集群进行复制,而且写入记录复制到备集群的顺序是不确定的。

    如上图所示这种极端情况下,还会导致主备集群数据的不一致。比如RegionServer1上最后一个未同步的写入操作是Put,

    而RegionA被移动到RegionServer2上的第一个写入操作是Delete,在主集群上其写入顺序是先Put后Delete,

    如果RegionServer2上的Delete操作先被复制到了备集群,然后备集群做了一次Major compaction,其会删除掉这个Delete marker,然后Put操作才被同步到了备集群,

    因为Delete已经被Major compact掉了,这个Put将永远无法被删除,所以备集群的数据将会比主集群多。

    解决这个问题的关键在于需要确保RegionServer2上的新写入操作必须在RegionServer1上的写入操作复制完成之后再进行复制。

    所以串行Replication引入了一个叫做Barrier的概念,每当Region open的时候,就会写入一个新的Barrier,其值是Region open时读到的最大SequenceId加1。

    SequenceId是HBase中的一个重要概念,每个Region都有一个SequenceId,其随着数据写入严格递增,同时SequenceId会随着每次写入操作一起写入到WAL中。

    所以当Region移动的时候,Region会在新的RegionServer重新打开,这时就会写入一个新的Barrier,Region被移动多次之后,就会写入多个Barrier,来将Region的写入操作划分成为多个区间。

    同时每个Region都维护了一个lastPushedSequenceId,其代表这个Region当前推送成功的最后一个写操作的SequenceId,

    这样就可以根据Barrier列表和lastPushedSequenceId来判断WAL中的一个写入操作是否能够复制到备集群了。

    以上图为例,Pending的写入记录就需要等待lastPushedSequenceId推到Barrier2之后才能开始复制。

    由于每个区间之间只会有一个RegionServer来负责复制,所以只有和lastPushedSequenceId在同一个区间内的RegionServer才能进行复制,

    并在复制成功后不断更新lastPushedSequenceId,而在lastPushedSequenceId之后各个区间的RegionServer则需要等待lastPushedSequenceId被推到自己区间的起始Barrier,

    然后才能开始复制,从而确保了Region的写入操作可以严格按照主集群的写入顺序串行的复制到备集群。

    # 串行复制链路
    add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", SERIAL => true

    # 设置为false,不可用
    set_peer_serial '1',false

    # 设置为true,可用
    set_peer_serial '1', true

    四、同步Replication

    同步Replication是和异步Replication对称的概念,其指的是主集群的写入操作必须被同步的写入到备集群中。

    异步Replication的最大问题在于复制是存在延迟的,所以在主集群整集群挂掉的情况下,备集群是没有已经写入的完整数据的,

    对于一致性要求较高的业务来说,是不能把读写完全切到备集群的,因为在这个时候可能存在部分最近写入的数据无法从备集群读到。

    所以同步Replication的核心思路就是在写入主集群WAL的同时,在备集群上写入一份RemoteWAL,只有同时在主集群的WAL和备集群的RemoteWAL写入成功了,才会返回给Client说写入成功。

    这样当主集群挂掉的时候,便可以在备集群上根据Remote WAL来回放出来主集群上所有写入记录,从而确保备集群和主集群数据的一致。

    需要注意的是,同步Replication是在异步Replication的基础之上的,也就是说异步Replication的复制链路还会继续保留,同时增加了新的写Remote WAL的步骤。

    对于具体的实现细节来说,首先是增加了一个Sync replication state的概念,其总共有三个状态, 分别是Active,Downgrade Active和Standby。

    这几个状态的转换关系如下图所示,Standby在提主的时候需要首先提升为Downgrade Active,然后才能提升为Active。但是Active是可以直接降级为Standby的。

    目前这个状态是保存在ReplicationPeerConfig中的, 其表示一个集群在这个ReplicationPeer中处于哪个状态。

    然后实现了一个DualAsyncFSWAL来同时写主集群的WAL和备份集群的Remote WAL。写WAL的操作是对于HDFS的rpc请求,其会有三种结果: 成功,失败或者超时。

    当超时的时候,对于HBase来说结果是不确定的,即数据有可能成功写入到WAL或Remote WAL里了,也有可能没有。只有同时写成功或者同时写失败的时候,

    主集群和备集群才会有一样的WAL,如果是主集群写WAL成功,写Remote WAL失败或者超时,这时候主集群WAL里的数据就有可能比备集群的Remote WAL多。

    相反如果写备集群Remote WAL成功了,而主集群的WAL写失败或者超时了,备集群的Remote WAL里的数据就有可能比主集群多。当两边都超时的时候, 就不确定那边多了。

    所以同步复制的关键就在于在上述情况下,如何确保主备集群数据的最终一致。即在切换主备集群的时候,Client应该始终从主备集群看到一致的数据。

    而且在主备没有达到一致的中间状态时,需要一些限制来确保Client没法读到这种中间不一致的结果。所以总结一下就是主备集群最终一致,

    但对于Client来说是强一致,即成功写入的数据无论主备集群都要一定能读到。具体的实现细节可以参考HBaseCon Asia 2018:HBase at Xiaomi[1]。

    对比异步复制来看,同步复制主要是影响的写路径,从我们的测试结果上来看,大概会有14%的性能下降,后续计划在HBASE-20422[2]中进行优化。

    五、自定义Replication Endpoint

     除了上述3种Replication之外,HBase还支持插件式的Replication Endpoint,可以自定义Replication Endpoint来实现各种各样的功能。

    引用:

  • 相关阅读:
    lua table
    lua basic
    lua5.4 coroutine的通俗理解
    HarmonyOS实战—实现双击事件
    HarmonyOS实战—单击事件的四种写法
    HarmonyOS实战—实现单击事件流程
    苹果CMS对接公众号教程
    Spring快速入门
    YYCMS搭建影视网站教程
    分享几个开源Java写的博客系统
  • 原文地址:https://www.cnblogs.com/caoweixiong/p/13606732.html
Copyright © 2011-2022 走看看