阿里雲基於NVM的持久化高性能Redis數據庫

背景

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）。可見，基於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能提供更高的存儲密度和更大容量的數據存儲空間，所以能夠有效下降單位數據存儲成本。基於NVM的字節尋址能力和與DRAM的速度差別，咱們設計了NVM非易失性內存和DRAM易失性內存間的數據換入與換出策略，能在不影響Redis基本性能的前提下，提升數據的存儲容量並節約成本。

結束語

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

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

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

文章連接：https://yq.aliyun.com/articles/621212