由於個人工作關系，接觸到了持久化內存的概念，覺得這個概念特別有意思，對於未來的編程模型會有很大的影響，甚至，很多的軟件（系統軟件）優化和架構會有很大的不同，甚至重寫。

• 背景知識

長久以來，我們一直接受的觀念是，數據從磁盤讀取到內存中，然後CPU從內存對數據進行操作，最後再從內存回寫到磁盤保存，完成整個數據的讀取，處理和保存。這個觀念中，內存容量很小，很貴，磁盤容量很大但是很便宜。從4k訪問延時或者吞吐量上來看，內存是要比磁盤快上1000倍或者以上的，然而，隨著Intel的黑科技技術傲騰（Optane）誕生，貌似這一假設有可能會被終結。

這玩意可以長得和我們普通內存一樣，可以插到內存插槽上，但是容量可以做到單根甚至是512GB，至於價格就不好說了，畢竟官方還沒有公布，肯定是會比內存便宜很多。但這玩意也叫PM（Persistent Memory，持久化內存），肯定訪問方式和內存還是會有點不太一樣，既然是持久化，那麽它和磁盤有什麽區別麽？

通常我們訪問磁盤，都需要走文件系統，內核，驅動程序，最後是磁盤本身的操作，當然，磁盤自身的操作時間（延時）會比較長，前面一些操作的時間基本可以被忽略。隨著磁盤越來越快，從傳統HDD到SSD到PCI-E SSD再到現在的傲騰技術，我們發現“磁”盤自身操作的延時越來越短，那麽相比之下，操作系統內核，驅動，文件系統所帶來的開銷就不能被忽略了，甚至會成為瓶頸，於是就有了新的持久化內存編程模型出來了。

應用程序會有3種模式可以訪問傲騰磁盤（插在內存插槽上的傲騰介質）：

• • 仍然是傳統的文件系統方式訪問文件，把傲騰當成普通的SSD用；
    • 這個訪問延遲可能會和訪問PCI-E SSD不會有太大差別，畢竟延時都浪費再文件系統，內核，驅動上了，更不用談現在的Java或者C++的文件API，通常都有“緩存”訪問，天知道需要在內存裏倒騰來倒騰去多少次最後才會寫到真正的設備裏；
    • 雖然看上去現有代碼不需要怎麽改動，但是性能優勢和PCI-E SSD比，如果沒有太大區別，除非其價格和PCI-E SSD可以拼一把，否則這種應用場景通常不會被考慮。
  • 用PM-Aware文件系統（可以持久化）
    • 會跳過文件系統本身的負載（比如文件緩存等），至於PM-Aware文件系統本身的負載有多大，就不得而知了，不知道Intel會不會公布他們的官方性能數據；相信應該是一個不錯的數字；
    • 標準文件API這一塊或許不是我們通常理解的標準C/C++/Java API，至少這些API底層需要重寫或者有PM-Aware文件系統提供新型API；
  • 應用程序直接訪問NVDIMM，操作系統內核把它當作內存用，並提供MMU的地址映射關系（可以不持久化）
    • 這塊是我覺得讓人很振奮的地方，理論上應該是應用程序可以獲得一個更大的內存，和普通的內存使用沒有什麽太大區別，訪問數據時，沒有了系統調用，文件系統等多個拖累。

相信官方應該是推薦後面兩種方案；（https://pmem.io）

• 個人的一些想法(隨想)
  • 單機版應用（包括系統程序）可能需要有對應的修改
    • 比如傳統的數據庫系統（MySQL/Oracle），大部分的優化是基於數據先寫內存，積累到一定量一次性刷到底層存儲系統，並保證一致性，但是現在有了PM-aware文件系統，數據存儲足夠快，數據是可以直接往底層設備上寫，並保證其一致性的，內存“緩存”的概念可能會慢慢弱化；
    • 高級語言對應的API和數據結構優化，比如常見的文件操作（java中的StringBuffer，BufferedReader等等) ,或許對於性能而言，反而會導致性能下降，需要開發新的API以支持PM-aware文件系統或者是直接內存訪問模式；
  • 分布式應用
    • 傳統數據傳輸走的是以太網（TCP/IP），後面是不是可以用RDMA直接對接PM？也會減少很多內核和驅動的負載。
    • 比如Apache Spark，Kylin這類所謂的In-memory分布式計算引擎，如果有相應改動，會極大提升計算效率，當然會涉及到一些列的數據結構上的優化和修改，讓它更適合訪問“PM”類型的內存特性；
    • 分布式緩存框架，比如Alluxio，Apache Ignite等也有很多機會獲得最好的性能或者延遲。
• 參考文檔
  • Alluxio
  • 持久化內存編程模型

持久化內存編程及其思考