ZK节点数过大导致不可用，引发ResourceManager挂掉
故障经过
晚上8点多突然发现flink任务大面积挂掉重启的告警，然后打开 yarn-ui进行查看发现 ui也挂了
根据情况以及日志，初步判定RM挂了，然后查看RM 日志，发现ZK连不上，怀疑ZK有问题， 然后又登录ZK集群，查看ZK日志
##ZK日志
为了尽快恢复故障，减少故障时间，决定重启RM，但是启动失败，感觉RM启动HANG住了，仍然不可用，日志如下
发现ZK链不上，那回头看ZK，首先也是开启了重启大发，将ZK重启了一下，根据日志发现ZK正常启动，但是 仍然发现RM链不上ZK,
这时候开始手动执行zk-client去链接，链接是正常的，然后神奇的事情发生了，执行ls命令时，直接OOM异常。。。
卧槽，这到底时为什么，一脸懵逼，不过问题大概就在这了，内存不够，就先加内存起来再说，直接改ZK启动内存，然后重启
然后再用zk-client链接，再执行ls命令，OK 正常了，狂喜，以为这下搞定了
然后去重启RM，悲剧发生了，RM一直卡在那里，也不报错，就是起不来~~~
他到底在干嘛呢？？？为了搞清楚这个问题，我们开始jstack RM，然后发现了这个
他卡在了，加载RMState, 到底这个东西有多大，我们查看了集群配置RMState 是 存放在 zk 中的，我们又看了一下zk的监控，然后惊呆了，ZK的节点总数80万个，，，大部分都是RMSTATE下的。。。
现在终于搞明白，他为什么卡住起来不了。如果等他加载完毕，估计几个小时又过去了，为了快速恢复我们改为启动不加载，修改集群配置
yarn.resourcemanager.recovery.enabled: false
然后将RMSTATE从存储在ZK上改为存储在HDFS上，修改配置
yarn.resourcemanager.store.class
org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore（原来配置）org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore（修改后的配置）
再追加一个新配置
yarn.resourcemanager.fs.state-store.uri: /yarn/system/rmstor
然后重新RM, 集群恢复正常，
最后为了ZK的稳定性清理ZK中的大量RMSTATE数据，问题虽然解决了，但是ZK中的80万的节点是怎么来的？正常情况下一个任务下的RMSTATE文件数量也就几个，整个集群也就1000多个任务，一般也就几千个，到底是什么导致他出现了80万个？ 未完待续~