轉載：https://blog.csdn.net/breakout_alex/article/details/107499035?utm_medium=distribute.pc_relevant.none-task-blog-baidulandingword-1&spm=1001.2101.3001.4242
參考：https://blog.csdn.net/qq_33440092/article/details/103863218
Hdfs雙緩沖機制
問題
Hdfs的Namenode如何抵抗住客戶端發起的高並發請求，主要是元數據的修改和更新，背景是hdfs的元數據是有兩份一份是NN中的內存元數據，一份是fsimage+edits文件（磁盤）。回憶之前提到過的寫數據流程，對於修改元數據的動作，比如上傳一個文件，創建新的目錄等都需要先寫入edits並要把元數據變化寫入到NN的內存元數據。最消耗性能的就是edits寫磁盤的動作存在IO開銷。
例子
每次請求NN修改一條元數據，比如申請上傳一個文件，需要在內存目錄樹中加入一個文件，都要寫一個edits log，寫edits log的兩個步驟
- 寫入本地磁盤
- 通過網絡傳輸給JournalNodes集群
針對寫入本地磁盤文件
大量客戶端同時寫會導致寫入本地磁盤文件時出現多線程安全問題，HDFS如何保證安全呢？
兩個方面
- 對每個寫入的edits log分配一個全局順序遞增的transactionid(txid),基於這個序號可以標識每個edits log的先后順序。
針對txid,要保證全局順序一致，就要加鎖保證安全，也就是每個修改元數據的線程都要先拿到鎖然后生成txid才能寫入edits log。
怎么設計呢？如下圖設計會存在什么問題？
我們發現NN本身可以用多線程接收多個客戶端發送過來的並發請求，但是如果按照上面的設計會發現多個線程修改內存元數據之后，在串行的寫editslog,這里面會有兩大性能殺手，本地磁盤+網絡傳輸。如果真是如上設計NN可以支撐的並發也就每秒幾十個。
HDFS解決方案
其中一個解決方案就是把釋放鎖的動作前移，也就是在獲取到鎖生成txid之后，就把數據寫入緩沖區就釋放鎖而不是落磁盤網絡傳輸之后再釋放鎖。但是事情不能這么就解決了，我們知道緩沖區也是有大小限制，所以緩沖區數據達到一定大小后還需要定期刷寫到磁盤，但是一塊內存不能同時並發讀寫一塊內存數據。
因此HDFS引入的雙緩沖機制，把一塊內存划分為兩個部分：
一個部分用於寫入數據
一個部分用戶讀取后寫入磁盤和Journalnode