背景
- 老版本HDFS存在空间泄漏以及空间预分配bug导致存在HBase RS进程挂掉风险
- RS内存配置过高会导致系统内存不足造成请求抖动和OOM RS进程挂掉，RS默认配置77G(60%),其他组件默认配置40G(31%)，修改重启后RS 62G(48%)避免系统内存不足。
经过
升级core-2过程中,高风险节点core-5(内存水位解决临界值)发生宕机，造成业务写入抛错， core-5宕机恢复流程完成，hbase服务恢复，Flink任务Failover后自动消费积压的kafka数据。
直接原因
本身带病的高危集群，升级HDFS过程中要移动region做热升级，触发内存临界值节点导致RS进程挂掉， 带来了写入该RS的一组数据（rowkey分布）写入失败。
思考：
1、升级，重启等高危操作，先切换至备库上（需要备库版本新，无大缺陷，主备规格一致），主库滚动重启OK后，再从备库切换为主库。
2、升级，重启等高危操作，不切换到备库上，在主库有宕机的情况下，人工在后台切换主备，耗时数秒。 主备容灾作为极端情况下的兜底方案，需要人为手动去切换主备库， 数秒时间差内还是会有写入数据失败的情况发生， 后期业务侧的异常捕获代码中，将写入失败的数据分流至第三方存储（MySQL或MQ）中， 即业务状态数据写入HBase在超时报错情况下，对缓存做数据做写入重试,避免发生数据不一致， 同时可以解决之前已经存在的 由于HBase抖动带来数据不一致，需要产品运维提工单修改数据的偶发问题。
关于Dual-Service
双活方案：99%流量打入A集群，读写RT较高的毛刺数据自动打入B集群， 数据通道对A,B集群之间数据做百ms级的延时同步。 带状态的业务侧不能容忍的延时，Dual-Service方案不适合这样的场景。
