摘要：?背景 Redis作為一款簡潔、高效的開源K/V數據庫，可以被用于內存緩存、持久化存儲等不同場景，大量服務于各類互聯網應用。同時也提供了豐富的功能配置，客戶可以根據各自業務需求，在讀寫性能、緩存容量、數據可靠性等方面作出靈活的選擇。

背景

Redis作為一款簡潔、高效的開源K/V數據庫，可以被用于內存緩存、持久化存儲等不同場景，大量服務于各類互聯網應用。同時也提供了豐富的功能配置，客戶可以根據各自業務需求，在讀寫性能、緩存容量、數據可靠性等方面作出靈活的選擇。

Redis提供了RDB和AOF兩種持久化方式供選擇，4.0中更是引入了RDB-AOF混合持久化的方式，整合RDB和AOF的優勢，提供更實時的數據持久化保證、更快的恢復速度和更緊湊的空間使用。針對AOF的寫入，Redis提供了兩種選項供選擇：

? always：aoflog實時寫入落盤，保證寫入數據的安全性，但寫入性能下降嚴重。

? everysec：buffer寫入aoflog，后臺定期刷盤，可以很好的保證寫入性能，但在failure場景下，需要承擔秒級新寫入數據丟失的風險。

這兩種模式需要用戶在性能和數據安全性之間做出取舍，魚和熊掌無法兼得。對一些對數據安全性有更高要求的場景，需要應用層協同來保證數據安全，會給系統設計和實現帶來一定的復雜度。另一方面，在Redis發生failover的時候，會有一個緩存預熱重建的過程，期間對應用會有一個可感知的不可服務時間、以及訪問延時抖動。

關于上述問題，很重要的一個原因在于目前DRAM和SSD（請忽略HDD）之間巨大的性能鴻溝。近幾年，備受學術界和工業界關注的NVM（Non-volatile Memory）?技術，給這類問題的解決帶來了新的機遇。

?

圖1：NVM產品的存儲層次結構

目前已有的NVM產品，對上層應用提供DIMM形態的訪問接口。作為一種NVM設備，相比于DRAM具備掉電不丟數據的特性，容量上也會比DRAM高出一個數量級，成本優勢明顯。相比于傳統SSD，不但讀寫速度更快（百ns量級），而且具備字節尋址的能力。同時也要看到，NVM產品仍然存在讀寫不對稱、順序和隨機訪問不對稱等特征。

從應用場景上來看，NVM產品可以定位于替代部分DRAM功能，支撐持久Memory或In-Memory應用。具體來說可被應用在如下場景：

? 持久化內存：作為數據持久層，對數據一致性要求很高的持久化系統，同時兼顧數據可靠性和數據讀寫性能。

? 內存數據庫：作為數據In Place空間，提供數據運行和持久化存儲空間。

? 系統日志卷：作為日志卷，例如，在HPC系統中通常采用Checkpointing實現對計算中間狀態進行持久化保存，這是一個耗時、耗系統吞吐量的過程。

基于NVM產品提供的字節尋址、持久化、高性能的能力，以及考慮到其讀寫、順序和隨機訪問不對稱等特性，對Redis作了細致的設計和深度的定制化改造，針對上面幾個問題取得非常好的測試效果。

性能分析

前面提到Redis的always模式通過實時flush操作確保AOF文件的實時持久化，但這會導致性能大幅下降。Everysec模式通過大幅減少flush操作的頻率，基于page cache緩沖對設備的讀寫訪問大幅提升QPS性能，但是這會引入秒級的數據丟失風險。而基于NVM產品提供的持久化能力可以非常優雅地解決這個問題，兼顧性能和可靠性。整個的數據流圖如下：

?

圖2: 基于NVM產品的數據讀寫流程

首先將AOF文件直接放在基于NVM產品的PMEM-aware filesystem上（比如EXT4?DAX模式），通過mmap將AOF文件映射到用戶態地址空間，之后對AOF的訪問操作就變成了非常輕量的直接load/store方式，而且要確保數據持久化也僅需要在用戶態執行persist操作（主要是cache?flush）?？梢?#xff0c;基于NVM產品的AOF持久化機制相比傳統的IO棧要輕量的多：

B? Bypass整個傳統IO棧（Block層->設備驅動等），實現直接load/store操作。

? 通過cache?flush操作即可實現持久化，取代了flush系統調用。

AOF機制的另一個問題是AOF文件的持續增大會造成巨大的空間浪費，所以阿里云Redis團隊通過后臺線程的方式按照一定的策略（考慮吞吐和資源占用量等）對AOF文件進行replay操作。即根據AOF命令在NVM產品上構造持久化的KV數據結構，然后完成回放的AOF文件就可以刪除，從而解決了AOF占用空間的問題。

之所以選擇后臺線程異步replay的方式在NVM上構建持久化數據結構，是因為該過程需要通過事務操作來保證寫操作的原子性和數據結構的一致性，耗時較大，所以數據先寫到DDR的方式可以保證客戶端寫操作的QPS不下降?？紤]到NVM擁有出色的讀性能，數據異步replay到NVM之后，會根據數據冷熱和內存占用量釋放部分value比較大的內存副本，轉而直接基于NVM提供讀服務。所以DRAM逐漸演變為NVM的寫cache和熱數據的讀cache，以充分發揮NVM的讀性能和成本優勢，同時規避NVM寫性能（相對）的短板問題。

在兩臺96核/384GB神龍服務器上，實測string數據結構的SET操作，從結果數據來看幾乎與everysec模式的性能持平，同時兼顧了always模式的數據安全性和everysec模式的高性能。

圖3：Redis寫入性能對比

Redis在重啟時需要進行數據恢復操作。原生Redis重啟后都需要從RDB和AOF中加載數據到內存，完成加載后才可以正常提供服務。經過實測，10GB左右數據的RDB加載時間大概為53秒左右，這段時間內Redis服務處于不可用狀態。而在基于NVM的方案中，Redis重啟后可以先基于NVM的持久化數據結構直接提供讀服務，DRAM數據結構重建完成后即可提供完整的讀寫服務。同樣針對10GB左右的數據集，系統shutdown?save后重啟，實測1秒內可以提供只讀服務，35秒內可以提供完整讀寫服務，整個數據恢復時間大幅下降。如下圖所示：

?

圖4: Redis?recovery時間對比

另外，原生Redis通過fork一個子進程來保存全量DB數據到RDB或AOF文件，即使相比上次保存的數據僅有一個key的變更，也依然會全量保存整個DB，顯然這不是一種高效的實現方式。并且該過程會對Redis帶來較大的性能抖動。而基于NVM的方案是一種持續增量持久化的方式，更加高效和平滑，這點對于在線服務來說至關重要。

NVM相比DRAM能提供更高的存儲密度和更大容量的數據存儲空間，因此可以有效降低單位數據存儲成本?；?/span>NVM的字節尋址能力和與DRAM的速度差異，我們設計了NVM非易失性內存和DRAM易失性內存間的數據換入與換出策略，能在不影響Redis基本性能的前提下，提高數據的存儲容量并節約成本。

結束語

整個方案中，充分發揮了NVM的字節尋址、持久化等能力，借助DRAM做cache來彌補NVM讀寫不對稱的問題，從而實現了高可靠、高性能、低成本的Redis數據庫，從測試數據可以看出NVM對Redis在持久化以及其他性能方面提升效果非常顯著。

除此之外，NVM相比DRAM能提供更高的存儲密度和更大容量的數據存儲空間，因此可以有效降低單位數據存儲成本。在不影響Redis基本讀寫性能的前提下，基于NVM和DRAM的動態數據輸入換出，是我們下一步工作的方向之一。

當然，目前方案仍存在一些待優化的點，比如：對于高寫入場景，replay性能跟不上DRAM寫入速度；failover時候，需要等DRAM重建完成才能提供寫服務等。后續會繼續跟進這些問題，結合技術和產品來一起合理改進。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里云基于NVM的持久化高性能Redis数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。