雲計算

Tair持久存儲系列技術解讀

Redis做為當今主流的內存數據庫支持許多豐富的數據結構,比如哈希表、集合,還有lua腳本、事務、消息訂閱等等高級特性,同時使用內存做為主要的存儲介質,支持高速訪問。

但是由於其數據全部存儲在內存,成本較高,而且對於海量數據存儲的支持也存在一些痛點,比如在AOFREWRITE和生成RDB快照時會有較高的latency spike,大數據量下全量同步耗時較長、失敗率較高。並且數據可靠性稍弱,RDB和AOF不能保證數據不丟失。

為了解決上述問題,拓寬Redis的應用場景,我們結合新技術新硬件推出了Tair持久存儲系列產品:容量存儲型和持久內存型,支持大容量存儲和更高的數據可靠性。

>>發佈會傳送門

點擊瞭解產品詳情

容量存儲型
9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

使用磁盤存儲就是其中的解決方案之一,利用磁盤可以降低成本並且提供海量存儲。但是在磁盤上實現redis也會有一些挑戰:

1.首先redis的數據結構都是基於內存實現,內存可以直接尋址,而磁盤是個塊設備,需要在磁盤上構建存儲引擎來支持redis數據結構訪問。

2.另外磁盤和內存有較大的性能差距,原生redis單線程的架構無法滿足吞吐需求,需要從架構設計上提升訪問性能。

應對這些挑戰,我們基於rocksdb進行了改造,提供了高性能的存儲引擎TairDB,並實現了redis數據結構向簡單kv的編碼映射,使redis數據能夠存儲在磁盤上;採用多線程的架構來提升訪問磁盤的性能;同時使用阿里雲ESSD高效雲盤為存儲底座,利用雲盤快照進行備份和全量同步,避免fork帶來的問題並提高全量同步效率。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

redis有五種基本數據類型,其中string可以直接映射到rocksdb的kv,但是其他一些複雜的數據結構hash、list、set、zset需要通過一定格式的編碼把redis的數據結構映射到rocksd的kv上。

我們把redis數據結構拆分為meta和data兩類,進行不同的編碼,通過meta可以去找到其對應的data,也即二級索引。

以hash為例,執行hset myhash myfield myvalue之後,hash表的名字myhash就會在meta中生成一份kv,其中key就是myhash,value會標誌它的屬性為hash表;myfield和myvalue會記錄在data中,再以key+類型+filed就可以索引到hash表的所有內容。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

為了實現多線程架構,首先需要解決key衝突的問題,這裡我們實現了key級別的鎖,這樣可以大大降低鎖衝突,提高併發度。命令執行過程中多個線程首先獲取key鎖,然後按命令的邏輯執行,通過預先設計好的編碼規則存取數據。最後再把結果以事務的方式提交給底層存儲引擎。每個命令的執行都是要在事務提交之後才會返回結果,這樣每一條命令都是持久化的,大大提升了數據可靠性。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

關於主備複製,全量複製使用雲盤快照提高效率。增量複製採用類似MySQL binlog的方式,事務提交之後同時也會寫入binlog,然後會有sender把binlog傳輸給備庫,binlog傳輸到備庫上時會首先保存為relaylog作為中繼,然後通過relaylog再回放應用,這樣有兩點好處:

1.支持semisync,只要relaylog落盤就可以認為事務在備庫也提交完成,不用等待relaylog應用,這樣既可以提升增量同步的效率,同時提供了更強的主備一致性保證。

2.支持併發回放,在relaylog中記錄併發度的元信息,不同的key就可以進行併發回放提高效率,同時相同的key仍然按序回放,保證主備一致性,不會造成數據錯亂。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

上圖為不同類型場景和實例規格下的性能測試結果,測試命令為時間複雜度O(1)的GET/SET,綜合性能中位數在開源版70%。

在數據小於內存的情況下大部分數據都會緩存在操作系統的page cache中,整體性能會優於數據大於內存的情況。規格越高的實例線程越多併發度也就越高,性能也相對越好。另外不同於內存中的GET/SET,磁盤上寫入數據需要有read modify write的過程,也即需要先讀取元數據才能進行修改,所以對於GET/SET寫性能要弱於讀性能。

持久內存型

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

傲騰持久內存是Intel推出的一款非易失性內存產品,在提供接近內存延時能力的同時保持持久化的能力, 理想情況下對於Redis場景來說是非常好的,因為數據寫入到持久內存中已經持久化,那麼就不需要額外的日誌和Checkpoint用來保證持久化的特性,同時傲騰持久內存在延遲上也比較接近內存優於傳統SSD,成本上對比內存也更加的便宜。

Redis基於傲騰持久內存能達到高性能的同時擁有較高的持久化能力,但是實際在工程實現會碰到非常大的挑戰,包括:

1.需要使用持久化內存的分配器來代替原有的內存分配器,分配器的元數據信息需要持久化,否則在恢復的時候會造成內存的洩露或者不一致。
2.原本String,Set,Hash這些數據結構和索引在異常的時候全部失效在恢復的時候重建,而現在這些數據都是持久化的,如何支持設計持久化的數據結構是目前工業界和理論界主要的研究方向之一
3.索引和數據的一致性,數據的完整性,這些都會在下一張NVM的挑戰中做更詳細的闡釋
4.持久內存在延時還是比內存更高,如何做好冷熱分離,讓系統擁有更高的性能。
5.如何擁有高性能的同時兼備強大的持久化能力。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

持久內存的使用分為兩大類Memory Mode和 AppDirecrt Mode, memory mode無需用戶改造但是沒有持久化內裡, 使用App Direct mode之後對比傳統SSD從block尋址轉為字節尋址,同時接口也從文件write/read轉為內存的load和store。

數據寫入內存的過程可能會停留在CPU L1,L2cache,需要調用類似CLWB和CLFLUSHOPT這樣的指令來刷到內存系統中,由於CPU只能保證8個字節的原子寫入,那麼對於一個16字節的寫很有可能在寫完第一個8字節的時候crash,後半部分沒有寫入成功這個就是所謂的partial writes, 上層應用在使用持久內存的時候需要額外的實現來保障數據持久問題。

下面的例子是一個雙向鏈表,傳統內存crash之後所有的數據丟失,而持久內存則保留了crash的狀態,因此會出現B的Next指針指向了C而C的Prev指針缺沒有指向B,這個時候的雙向鏈表是出於異常的狀態。 從鏈表衍生開來內存分配器中的管理結構也存在這個問題,會出現內存洩露等情況。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

由於持久化的挑戰,目前主流使用持久內存的方式都是當做Memory或者使用AppDirect但是不支持持久化,阿里雲Tair持久內存版的是基於傲騰持久內存的自研引擎,解決了持久化編程中遇到的各種挑戰,撘配阿里雲官方提供的Linux操作系統鏡像Aliyun Linux,Aliyun彈性計算服務首次(全球首家)在神龍裸金屬服務器上引入傲騰持久內存,深度優化完善支持,為客戶提供安全、穩定、高性能的體驗。

阿里雲持久內存版Tair的每一條記錄都確保寫入AEP並且持久化才返回,極大的提升數據的可靠性, 同時在讀取路徑上使用Dram緩存如索引等熱點數據結構和元數信息,來加速數據訪問的存取。

9989c5b90f96dedb20d3e717592eeed2c54bdb86.jpeg

在神龍裸金屬機器上,我們使用相同配置進行了Tair持久內存版和Redis6.0的性能對比, 整體上吞吐為社區內存版本的90%, 延時上由於沒有AofRewrite的干擾,P95的延時更加的穩定。

Leave a Reply

Your email address will not be published. Required fields are marked *