当双Observer NameNode配置中，主动关闭一个Observer节点时，客户端请求未能正确Failover到另一个Observer节点。通过分析源码和抓取火焰图，发现由于历史编辑日志丢失导致Observer节点的事务ID落后，从而无法处理读请求。解决方法是停止受影响的Observer节点，同步最新的fsimage和editlog，再重启，确保事务ID与Active NN一致。
描述下现象：
节点角色：
node1: Active NN
node2: Standby NN
node3: Observer NN
node4: Observer NN
测试过程：
客户端读数据，能够直接找到node3这个Observer NN去读，接着我们把node3的namenode给kill掉，理论上讲客户端读数据的请求应该会failover到node4这个Observer NN上，但是测试中，发现node4的NN的rpcQueueTimeOps激增，说明rpc请求确实被failover到node4上了，但是只是入队了，并没有处理请求，审计日志也没有任何信息（证明确实没处理读请求）。
因此我们需要弄清楚这个问题的原因，并解决它。
解决过程：
对node4上的Observer NN抓火焰图：
发现了requeueCall操作比较多。因此看下requeueCall方法什么时机被调用，搜到源码中，是在Server#Handler#run方法中调用，问题的关键就在于if条件里面的与操作都是真，才会进入到if条件语句里执行requeue操作。在我的场景下，前两个条件肯定都是满足的，因此推出第三个条件为真了。也就是说client侧看到的state id要比服务端的LastSeenStateId还要大，那此时肯定不能读数据呀，因为Observer NN的对读一致性的实
订阅专栏 解锁全文
691
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
