hadoop 2.4 namenode ha的原理是什么

本篇內(nèi)容介紹了“hadoop 2.4  namenode ha的原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

在2.0 的HA部分，我們可以看到相比原來的1.0，多了DFSZKFailoverController ，JournalNode 進程。

DFSZKFailoverController顧名思義就是用于整個主備切換的控制器。

JournalNode 是active和standby元數(shù)據(jù)共享的傳輸介質(zhì)。

而DFSZKFailoverController主要負責active NN的選舉通過ActiveStandbyElector來實現(xiàn)，對于nn本身的監(jiān)控通過HealthMonitor類來實現(xiàn)，下面我們來分析一下HealthMonitor來究竟做了哪些工作以及對NN的監(jiān)控調(diào)用流程。

對于NN的狀態(tài)，定義了如下幾類：

public enum State {
    /**
     * The health monitor is still starting up.
     */
    INITIALIZING,
    /**
     * The service is not responding to health check RPCs.
     */
    SERVICE_NOT_RESPONDING,
    /**
     * The service is connected and healthy.
     */
    SERVICE_HEALTHY,
    /**
     * The service is running but unhealthy.
     */
    SERVICE_UNHEALTHY,
    /**
     * The health monitor itself failed unrecoverably and can
     * no longer provide accurate information.
     */
    HEALTH_MONITOR_FAILED;
  }

可以看到定義了，ok or failed兩類狀態(tài)。

對于監(jiān)控的結果，healthMonitor來通過設置回調(diào)函數(shù)來實現(xiàn)。

public void addCallback(Callback cb) {
    this.callbacks.add(cb);
  }
  
 

  public synchronized void addServiceStateCallback(ServiceStateCallback cb) {
    this.serviceStateCallbacks.add(cb);
  }

addXXXCallback可以動態(tài)添加事件回調(diào)函數(shù)。

真實監(jiān)控NN的部分

private class MonitorDaemon extends Daemon

通過內(nèi)部類MonitorDaemon來實現(xiàn)。實現(xiàn)在run方法，通過源碼可以看到run方法調(diào)用了

public void run() {
      while (shouldRun) {
        try { 
          loopUntilConnected();
          doHealthChecks();//監(jiān)控主方法
        } catch (InterruptedException ie) {
          Preconditions.checkState(!shouldRun,
              "Interrupted but still supposed to run");
        }
      }
    }

進行監(jiān)控

我們來看下，這部分源碼：

/**
   * 狀態(tài)監(jiān)測
   * @throws InterruptedException
   */
  private void doHealthChecks() throws InterruptedException {
    while (shouldRun) {//只有在關閉的時候shouldRun=false,其他一直是true
      HAServiceStatus status = null;//NN的狀態(tài)
      boolean healthy = false;//定義健康程度
      try {
     //proxy為HAService的一個rpc代理，由NameNodeRpcServer實現(xiàn)HA的NN部分
        status = proxy.getServiceStatus();
        //本質(zhì)上調(diào)用了NN的monitorHealth方法，而NN的監(jiān)控方法，主要是對系統(tǒng)資源的一個檢查，如無異常，直接返回
        //有異常會throw出HealthCheckFailedException, AccessControlException異常
        proxy.monitorHealth();
        healthy = true;
      } catch (HealthCheckFailedException e) {//異常
        LOG.warn("Service health check failed for " + targetToMonitor
            + ": " + e.getMessage());
        enterState(State.SERVICE_UNHEALTHY);
      } catch (Throwable t) {//未知異常，一般是對應的NN沒有啟動
        LOG.warn("Transport-level exception trying to monitor health of " +
            targetToMonitor + ": " + t.getLocalizedMessage());
        RPC.stopProxy(proxy);
        proxy = null;
        enterState(State.SERVICE_NOT_RESPONDING);
        Thread.sleep(sleepAfterDisconnectMillis);
        return;
      }
     
      if (status != null) {
        setLastServiceStatus(status);
      }
      if (healthy) {
     //設置狀態(tài)，用于通知回調(diào)函數(shù)
        enterState(State.SERVICE_HEALTHY);
      }
      Thread.sleep(checkIntervalMillis);
    }
  }

而NN的監(jiān)控，也比較單純：

synchronized void monitorHealth() 
      throws HealthCheckFailedException, AccessControlException {
    namesystem.checkSuperuserPrivilege();
    if (!haEnabled) {
      return; // no-op, if HA is not enabled
    }
    getNamesystem().checkAvailableResources();
    if (!getNamesystem().nameNodeHasResourcesAvailable()) {
      throw new HealthCheckFailedException(
          "The NameNode has no resources available");
    }
  }

可以看到其實監(jiān)控部分，就是一個rpc不斷的發(fā)送請求，讓NN自檢測然后在返回相應的數(shù)據(jù)。

“hadoop 2.4  namenode ha的原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！