架构层面看，HBase在CAP定理中选择了C，以较弱的可用性为代价换取强一致性，数据层面依赖HDFS保证数据安全，计算层面region无副本。

这样当region迁移、分裂、合并、RS宕机等情况发生时，对应region都会有短时不可用；而作为高吞吐的数据服务，客户端往往都会大量使用线程池，少量region不可用会迅速形成木桶短板，进而放大为整体TPS掉底。

社区提供的region replica功能一定程度上可以缓解这一问题，但一方面目前这个feature可靠性还不算高，社区仍在推进各种加固和改善，目测稳定的目标release版本可能要放到未发布的3.0了；另一方面端上服务需要双机房，保证容灾和降级，而replica是集群内的region副本，显然也不能支持。

1. 两个集群分别创建主备测试表，构建replication

2. ycsb打入100w测试数据

3. 测试组打开多路读，对照组关闭多路读，各发起10w次scan

4. 客户端统计max、P999、P99

3.2 测试结论

max对比

P999对比

P99对比

多路读对于max和P999有较佳优化效果，可以有效打磨毛刺。

▍4.未尽事项和思考

1. 多路读功能基于replication实现，因此只能实现最终一致性，备集群读到的数据有可能和主集群存在差异；

2. 目前此功能仅作用于查询，主集群宕机时，最新数据无法同步，因此备集群查询最新数据可能查询不到；

3. HBase的scan操作可能分解为多次RPC，由于相关session信息在不同集群间没有同步，数据也不能保证完全一致，因此多路读只在第一次RPC时生效，之后的请求会固定访问第一次RPC时最终使用的集群。

多路读本质上是多活建设，但CAP较难跨越，多活可以提供高可用能力，但强一致性很难得到保障。

但我们可以通过“让用户选择”的方式来解决这一问题：

• 方案一：多活 + 最终一致性

• 方案二：主备 + 强一致性

对于方案一，当前的多路读实现了读链路的多活，写链路仍有优化空间，例如提升replication效率、降低两集群间数据lag等；

对于方案二，可以基于社区的同步replication实现，此外failover的功能仍需我们做更多工作，实现更加智能的自动切换，降低用户感知。

3. 

HBase-ZGC应用实践

▍1.为什么要更换GC算法？

随着滴滴内部越来越多的端上和类端上业务使用HBase作为存储引擎，用户对HBase读写延迟稳定性的要求也越来越高，HBase的GC毛刺问题尤为突出，G1无法满足性能需求。

好消息是JDK15在9月15号正式发布，划时代的ZGC正式转正，我们决定尝试用ZGC来解决GC毛刺问题。

ZGC（The Z Garbage Collector）：ZGC是JDK11之后发布的一款可伸缩的低延迟JVM垃圾收集器。

ZGC官方的设计目标如下：

• Max pause times of a few milliseconds(*)

• Pause times do not increase with the heap or live-set size (*)

• Handle heaps ranging from a 8MB to 16TB in size

ZGC 是一个并发的、单代的、基于区域的、NUMA 感知的压缩收集器，Stop-the-world 阶段仅限于根扫描，因此 GC 暂停时间不会随堆或活动集（live set）的变大而增加。

ZGC 的核心设计原则是将Load barriers与染色对象指针结合使用，这使得 ZGC 能够在 Java 应用程序线程运行时执行并发操作，例如对象重定向。从 Java 线程的角度来看，在 Java 对象中加载引用字段的行为受到加载屏障的影响。除了对象地址之外，colored oops 还包含加载屏障使用的信息，以确定在允许 Java 线程使用指针之前是否需要采取某些操作。

ZGC相比G1

• 更低延迟：GC停顿时间更短，不超过 10ms

• 更大内存：堆内存支持范围更大（8MB-16TB）

  
  

SPECjbb 2015基准测试，128G堆，ZGC的暂停时间远低于G1

相较于G1只有写屏障没有读屏障，复制移动的过程需要Stop the world，ZGC通过读屏障、Remark标记和重定向表来并发拷贝非GC Roots对象，尽可能的减少了Stop the world。

官方的性能测试对比可以参考JEP333。本文主要介绍HBase场景的ZGC应用实践，对ZGC的原理不展开介绍。

▍2. HBase应用ZGC实践

2.1 选择JDK版本

由于需要在生产环境使用，而Orace JDK商业使用开始收费，所以我们需要一个免费版的JDK。经过对比，我们最终选取了AdoptOpenJDK的JDK15版本。

1）AdoptOpenJDK 是社区（伦敦JUG）维护版的OpenJDK，提供预构建的二进制文件，主要维护LTS及最新版本；和OpenJDK一样，AdoptOpenJDK 也支持 GPL 协议且免费，不同的是OpenJDK只会由Oracle提供6个月的安全更新，而AdoptOpenJDK则由社区提供至少4年的免费长期支持（LTS）。

2）选择JDK15的原因： 

• JDK11存在小概率crash的问题

• ZGC在JDK15版本正式生产环境可用

2.2 编译HBase（基于AdoptOpenJDK15）

滴滴内部使用的HBase版本是基于社区1.4.8基础上开发的版本，不支持JDK11及以上版本的编译，所以需要解决一些编译问题。

社区3.x及2.3.x版本开始支持JDK11，参考 HBASE-22972。在1.4.8版本的编译过程中，主要遇到了以下几类编译问题：

• 1. 部分类找不到或被删除，比如javax.xml.ws.http.HTTPException。解决办法：找到替换类或依赖包；

• 2. 一些类不可读，比如sun.nio.ch.DirectBuffer。解决办法：运行时添加--add-exports=java.base/sun.nio.ch=ALL-UNNAMED；

• 3. 依赖的组件包不支持JDK15，如Jetty、Jruby等。解决办法：升级对应的组件到高版本；

• 4. 编译插件不支持JDK15，如maven-shade-plugin、extra-enforcer-rules等。解决办法：升级对应的插件到高版本。

2.3 应用ZGC的效果：

1、顺序读场景ZGC和G1性能表现对比