hbase客户端重试机制如何保证系统的容错性和低延迟性
HBase客户端Rpc的重试机制以及客户端参数优化。
HBase客户端基于退避算法的重试机制
1、业务用户一方面比较关注HBase本身服务的读写性能：吞吐量以及读写延迟，
2、另一方面也会比较关注HBase客户端使用上的问题，主要集中在两个方面：是否提供了重试机制来保证系统操作的容错性？是否有必要的超时机制保证系统能够fastfail，保证系统的低延迟特性？
3、HBase客户端提供的重试机制，并通过配置合理的参数使得客户端在保证一定容错性的同时还能够保证系统的低延迟特性。
RpcRetryingCall函数是Rpc请求重试机制的实现，所以可以有两点推断：
1、HBase客户端请求在那个时间段网络有异常导致rpc请求失败，进入重试逻辑
2、根据HBase的重试机制（退避机制），每两次重试机制之间会休眠一段时间，即上图115行代码，这个休眠时间太长导致这个线程一直处于TIME_WAITING状态。
出现的将近几个小时的堵塞无请求，除非2中情况
情况1：配置有问题：需要客户端检查hbase.client.pause和hbase.client.retries.number两个参数配置出现异常，比如hbase.client.pause参数如果手抖配成了10000，就有可能出现几个小时阻塞的情况
//
HBase 客户端暂停
hbase.client.pause = 100 毫秒 默认
HBase 客户端最大重试次数
hbase.client.retries.number = 35 默认次数
情况2：网络持续有问题：如果线程1持有全局锁重试失败之后退出，线程2竞争到这把锁，此时网络依然有问题，线程2会再次进入重试，重试8min之后失败退出，循环下去，也有可能出现几个小时阻塞的情况
//小结：情况1 出现的概率很低，基本上出现 客户端请求无响应，堵塞无请求的情况，网络持续有问题是很大的原因。
通过监控和小伙伴确认之后发现：在事发当时（凌晨0点～早上6点）确实存在很多服务因为云网络升级异常发生抖动的情况出现。
HBase Rpc重试机制
HBase的重试机制是这次异常发生的关键点，有必要对其进行一次解析。HBase执行rpc失败之后会执行重试操作，
重试的最大次数可以通过配置文件配置，对应的参数为hbase.client.retries.number,0.98版本中该参数的默认值为31。
//在一定时间内，不断的重试后，还没有成功响应的话，最后会放弃连接到集群
客户端参数优化实践
很显然，根据上面第二部分和第三部分的介绍，一旦在网络出现抖动的异常情况下，默认最差情况下一个线程会存在8min左右的重试时间，从而会导致其他线程都阻塞在regionLockObject这把全局锁上。为了构建一个更稳定、低延迟的HBase系统，除过需要对服务器端参数做各种调整外，客户端参数也需要做相应的调整：
- hbase.client.pause:默认为100，可以减少为50
//cdh中 HBase 客户端暂停
hbase.client.pause = 100毫秒 - hbase.client.retries.number:默认为31，可以减少为21
//HBase 客户端最大重试次数
hbase.client.retries.number = 35
修改后，通过上面算法可以计算出每次连接集群重试之间的暂停时间将依次为：
［50，100，150，250，500，1000，2000，5000，5000，5000，5000，10000，10000，…，10000］
客户端将会在2min内重试20次，然后放弃连接到集群，进而会再将全局锁交给其他线程，执行其他请求。
详细讲解了HBase Rpc的重试机制以及客户端参数优化。
参考链接
HBase最佳实践 – 客户端重试机制 http://hbasefly.com/2016/06/04/hbase-client-1/