hdfs的四大機制和兩大核心

四大機制：

（1）心跳機制：

  介紹： hdfs是主從架構，所有為了實時的得知dataNode是否存活，必須建立心跳機制，在整個hdfs運行過程中，dataNode會定時的向nameNode發送心跳報告已告知nameNode自己的狀態。
   心跳內容：
     - 報告自己的存活狀態，每次匯報之后都會更新維護的計數信息
     - 向nameNode匯報自己的存儲的block列表信息
   心跳報告周期：

<property>
              <name>dfs.heartbeat.interval</name>
              <value>3</value> //單位秒
</property>

   nameNode判斷一個dataNode宕機的基準：連續10次接收不到dataNode的心跳信息，和2次的檢查時間。
  檢查時間：表示在nameNode在接收不到dataNode的心跳時，此時會向dataNode主動發送檢查

<property>
                  <name>dfs.namenode.heartbeat.recheck-interval</name>
                  <value>300000</value> //單位毫秒
</property>

  計算公式：2dfs.namenode.heartbeat.recheck-interval+10dfs.heartbeat.interval=310+3002=630s=10.5min

（2）安全機制：

   介紹：hdfs在啟動的時候，首先會進入的安全模式中，當達到規定的要求時，會退出安全模式。在安全模式中，不能執行任何修改元數據信息的操作。
   hdfs的元數據的介紹（三個部分）：
    - 抽象目錄樹
    - 數據與塊的對應關系（文件被切分成多少個塊）
    - block塊存放的位置信息
   hdfs元數據的存儲位置：
    - 內存：內存中存儲了一份完整的元數據信息（抽象目錄樹、數據與塊的對應關系、block塊存放的位置信息）
    - 硬盤：抽象目錄樹、數據與塊的對應關系
    注意：其中內存中的元數據的block塊存放的位置信息，是通過dataNode向nameNode匯報心跳時獲取的，硬盤中的元數據，是因為內存中的元數據在機器宕機時就自動消失，所以需要將內存中的元數據持久化到硬盤
而硬盤中的元數據只有抽象目錄樹、數據與塊的對應關系，沒有block塊存放的位置信息
   nameNode在啟動的所作的操作：
集群的啟動順序：nameNode---》dataNode---》secondaryNameNode
   將硬盤中的元數據信息加載內存，如果是第一次啟動集群，此時會在本地生成一個fsimage鏡像文件，接收dataNode匯報的心跳，將匯報中的block的位置信息，加載到內存。當然就在此時hdfs會進入安全模式。
  退出安全模式的條件：
    - 如果在集群啟動時dfs.namenode.safemode.min.datanodes（啟動的dataNode個數）為0時，并且，數據塊的最小副本數dfs.namenode.replication.min為1時，此時會退出安全模式，也就是說，集群達到了最小副本數，并且能運行的datanode節點也達到了要求，此時退出安全模式
    - 啟動的dataNode個數為0時，并且所有的數據塊的存貨率達到0.999f時，集群退出安全模式（副本數達到要求）

<property>
     <name>dfs.namenode.safemode.threshold-pct</name>
     <value>0.999f</value>
</property>

   手動退出或者進入安全模式

      hdfs dfsadmin -safemode enter 進入
        hdfs dfsadmin -safemode leave 退出
        hdfs dfsadmin -safemode get 查看

（3）機架策略（副本存放策略）：

  第一個副本，放置在離客戶端最近的那個機架的任意節點，如果客戶端是本機，那就存放在本機（保證有一個副本數），第二個副本，放置在跟第一個副本不同機架的任意節點上，第三個副本，放置在跟第二個副本相同機架的不同節點上。
   修改副本的方法：
     1. 修改配置文件：

<property>
 <name>dfs.replication</name>
 <value>1</value>
</property>

     2. 命令設置： hadoop fs -setrep 2 -R dir

（4）負載均衡：

  hdfs的負載均衡：表示每一個dataNode存儲的數據與其硬件相匹配，即占用率相當
  ，如何手動調整負載均衡：
    - 集群自動調整負載均衡的帶寬：（默認為1M）

<property>
        <name>dfs.datanode.balance.bandwidthPerSec</name>
        <value>1048576</value> //1M
</property>

    - 告訴集群進行負載均衡：start-balancer.sh -t 10% 表示節點最大占用率與節點的最小的占用率之間的差值當超過10%時，此時集群不會立刻進行負載均衡，會在集群不忙的時候進行。

兩大核心：

（1）文件上傳：

• 使用hdfs提供的客戶端client，向遠程的namenode發起RPC請求。
• namenode會檢查要創建的文件是否已經存在、創建者是否有權限，成功則會為文件創建一個記錄，否則向客戶端拋出異常。
• 當客戶端開始寫入文件的時候，客戶端會將文件切分成多個packets，并在內部以數據隊列“data queue（數據隊列）”的形式管理這些packet，并向namenode申請blocks，獲取用來存儲replicas的合適的datanode列表，列表的大小根據namenode中的replication個數來設定。
• client獲取block列表之后，開始以pipeline（管道）的形式，將packet寫入所有的replicas中，客戶端把packet以流的形式寫入到第一個datanode中，該datanode把packet存儲之后，在將其傳遞到此pipeline中的下一個datanode，直到最后一個 datanode。
• 最后一個 datanode 成功存儲之后會返回一個 ack packet（確認隊列），在 pipeline 里傳遞至客戶端，在客戶端的開發庫內部維護著"ack queue"，成功收到 datanode 返回的 ackpacket 后會從"data queue"移除相應的 packet。
• 如果傳輸過程中，有某個datanode出現了故障，那么當前pipeline會被關閉，出現故障的節點，會被剔除此pipeline，剩余的block會繼續剩下的的 datanode 中繼續以 pipeline 的形式傳輸，同時 namenode 會分配一個新的 datanode，保持 replicas 設定的數量。
• 客戶端完成數據的寫入后，會對數據流調用close方法，關閉數據流
• 只要寫入了 dfs.replication.min（最小寫入成功的副本數）的復本數（默認為 1），寫操作就會成功，并且這個塊可以在集群中異步復制，直到達到其目標復本數（dfs.replication的默認值為 3），因為namenode已經知道文件由哪些塊組成，所以他在返回成功前只需要等待數據塊進行最小量的復制。
• 最后當這個文件上傳成功后，此時namenode會將預寫如日志的操作，同步到內存中

  （2）文件下載：

  

• 客戶端對nameNode發送下載的指令，hadoop fs -get /a.txt
• nameNode做一系列的校驗（是否權限、文件是否存在..）
• nameNode向client發送block的位置信息，根據情況發送一部分或者全部
• client計算出最進行DN，然后建立連接，進行文件下載
• client每下載一個塊就會做CRC校驗，如果下載失敗，client會向nameNode匯報，然后從其他的DD相應的塊的副本，此時nameNode會記錄這個可能故障的DN，在下次上傳或者下載的時候，盡量不使用它。
• 當所有的塊下載成功的時候，client向nameNode匯報成功信息

  補充元數據的合并：

  這是在分布式的基礎上，secondaryNamenode對元數據的合并：
  
  合并時機：
  A：間隔多長時間合并一次

          <property>
            <name>dfs.namenode.checkpoint.period</name>
            <value>3600</value> //單位秒
          </property>

  B：操作日志記錄超過多少條合并一次

  <property>
            <name>dfs.namenode.checkpoint.txns</name>
            <value>1000000</value>
   </property>

• 集群啟動時，加載fsimage鏡像文件到內存，如果是第一啟動集群或者集群正常關閉之后重啟此時nameNode會在硬盤中合并一個fsimage鏡像
• seconddaryNameNode定時（1分鐘）發送檢驗給nameNode，查看是否需要進行合并
• 得知nameNode需要進行元數據合并
• seconddaryNameNode向nameNode發送合并請求
• nameNode將edits_inprogress_000095 根據seen_txid進行回滾，并且生成一個新的空的edits_inprogress_000096，繼續記錄操作日志
• secondaryNameNode將回滾的edits和最新的fsiamge進行本地拉去
• secondaryNameNode將edits和最新的fsiamge進行合并，在內存中根據edits修改fsiamge
• secondaryNameNode將合并后的fsiamge推送回namenode。并在本地保存一份。