一 问题列表及解决方案
问题1 服务端replication CallQueue被打满
regionserver日常信息如上图所示，很明显服务端的replication CallQueue被打满是因为
业务侧hbase.ipc.server.max.callqueue.size使用默认值1G，建议业务修改配置 <property> <name>hbase.ipc.server.max.callqueue.size</name> <value>5368709120</value> </property>
查看服务端监控证实replication call queue确实被打满
建议业务修改以下配置项
<property> <name>hbase.regionserver.replication.handler.count</name> <value>60</value> </property>
增加目标集群的replication请求处理的线程数，业务使用的是默认值3。
梳理业务逻辑发现源集群针对每个table都建立了peer，这样存在的问题有：
1 单个HLog被多次消费
replication时源集群会在zk上创建/hbase/replication/peers/peers目录，rs启动时在对应的 rs 的 peer 子 znode 下会添加文件，
addSource 时，rs 启动时把相应 HLog 文件名添加上 preLogRoll 时，把新滚动的 HLog 添加上 FailOver 时，把挂了的 rs 的 HLog 文件名和 checkpoint 移动到相应 rs 的znode上
单RS上存在多个表，WAL都在一个HLog中，表粒度的peer会导致，单个HLog被多个znode hold，只有最后一个peer消费完成后，才会删除。 另外多次seek hlog会占用源集群的cpu和磁盘io。 建议业务将表粒度的peer修改为集群力度，具体修改如下：
add_peer '1','zk:2181:/hbase','table1;table2'
