hbase-snapshot流程以及追踪思路

问题

线上偶有export任务snapshot失败的问题存在，和RIT问题是同类问题，region状态更新过慢，仔细进行流程研究。

snapshot主体流程

1.snapshot enable table流程-- master侧不包括RS侧，RS侧另做图

​​

2.RS侧分布式快照

​​

3.根据排查极有可能是zk的问题，再给出详细的zk路线图，通过该图去寻找zk的通信是否存在问题

关键点，zookeeperWatcher，通过watch对节点进行监测

1.takeSnapshotHandler process --- procedure call

sendGlobalBarrierStart : 给所有参与procedure的member发送消息，开始子过程并且调用acquireBarrier方法，RS snapshot的主要方法在insideBarrier中，所以这一步直接成功

waitForLatch----- 等待所有acquire节点（此处是知道需要多少RS回执的）

sendGlobalBarrierReached：所有的barrier都到齐了，开始触发执行member的insideBarrier方法

waitForLatch----- 等待所有的reach节点（countDownLatch 为RS数目，到达数目后即全部做完）

sendGlobalBarrierComplete：收尾工作，删除znode等

2.Subprocedure call

acquireBarrier：do nothing

sendMemberAcquired: member已经准备完毕，等待全局Barrier

waitForReachedGlobalBarrier：等待全局barrier到达，然后执行insideBarrier

insiderBarrier: 执行FlushSnapshotSubprocedure，snapshot首先flush然后将region信息写入

sendMemberCompleted：在zk reach节点上写入自己的信息，表示自己已经做完了

验证ZK节点是否出现问题

采用测试表进行测试，影响的RS服务器为一台，只有一个节点可以看出更多问题，给相关类通过动态设置logLevel进行debug，找出master zk regionServer的交互信息

打开ZK debug日志，追踪如下过程即可发现问题~

1.procedure， start

2.sendGlobalBarrierStart生成节点，procedure生成新节点/hbase/online-snapshot/acquire/snapshot4，此时所有的regionServer zookeeperWatch都会探测到这个节点children发生改变，于是知晓有新的procedure需要执行（所有节点），只有被检测的regionServer列表才会让latch减少，减少为0即所有的RS都准备完毕

RS收到消息已经是2分钟以后了，这个时候才真正开始进行RS侧的操作（理论上应该是一瞬间完成）

3.RS测执行acquireBarrier以及sendMemberAcquired并开始等待全局Barrier。而Zookeeper正在协调所有acquire节点，如果所有节点准备完毕则生成/hbase/online-snapshot/reach/snapshot4节点

4.等待ZK侧收到所有的acquire节点之后，RS侧收到reach节点创建信息，进行后续的insiderBarrier流程，执行完成snapshot只剩下收尾的complete阶段

5.procedure执行完毕

同时在zk协调的过程中，regionServer收到节点的消息时间各异

收到同一个创建时间，regionServer的watch反应的时间点截然不同，反复测试多次之后，发现每个RS对节点创建的zKwatch反应时间几乎不会一致。

结论

根据以上结论，可以得知，如果不是zk based通信的话，那么snapshot的速度一定非常快

对空表进行测试，online snapshot和offline snapshot（disabled snapshot都是在master做的，没有zk参与）

可以发现disable之后几乎就是一瞬间完成了snapshot，结论是zk based通信出现问题

参考资料：

https://www.iteye.com/blog/ppg-1888453​​

Apache HBase – Apache HBase™ Home

hbase源码