墨天輪評測：GaussDB(for Redis)穩定性與擴容表現

本文轉載自墨天輪：https://www.modb.pro/db/171623

GaussDB(for Redis) 是華為云推出的企業級Redis，采用計算存儲分離架構，兼容Redis生態的云原生NoSQL數據庫，基于共享存儲池的多副本強一致機制，支持持久化存儲，保證數據的安全可靠。具有高兼容、高性價比、高可靠、彈性伸縮、高可用、無損擴容等特點。

GaussDB(for Redis)滿足高讀寫性能場景及容量需彈性擴展的業務需求，廣泛使用于電商、游戲以及視頻直播等行業。即可作為前端緩存支撐大并發的訪問，也可作為底層數據庫負責核心數據可靠存儲。

接下來我們使用采用Redis Labs推出的多線程壓測工具memtier_benchmark對比測試下GaussDB(for Redis) 和原生Redis的特性差異。

目錄導航

1、創建GaussDB(for Redis)實例

2、安裝memtier_benchmark

3、數據批量裝載

向GaussDB(for Redis) 中裝載數據

向原生Redis中裝載數據

4、實例緊急擴容

GaussDB(for Redis)擴容到16G

原生Redis擴容到16G

5、數據淘汰問題

插入數據到GaussDB(for Redis)

插入數據到原生Redis

6、測試總結

1、創建GaussDB(for Redis)實例

在華為云通過控制臺購買GaussDB(for Redis)實例，測試實例的配置為8G容量，如下所示。

如截圖所示，GaussDB(for Redis)提供了統一的負載均衡地址和端口，方便應用程序訪問高可用的Redis服務。持久化數據存儲空間直觀展示了數據量及容量上限。另外，依托于GaussDB(for Redis)存算分離的架構，實例的容量和性能可以按需分別擴展：

如需更多容量，只需點擊“磁盤擴容”；

如需更高的吞吐性能，則通過“規格變更”或“添加節點”完成。

2、安裝memtier_benchmark

使用與GaussDB(for Redis)測試實例相同子網的ECS云服務器，部署memtier_benchmark測試環境

# yum install autoconf automake make gcc-c++ # yum install pcre-devel zlib-devel libmemcached-devel openssl-devel # git clone https://github.com/RedisLabs/memtier_benchmark.git # cd memtier_benchmark # autoreconf -ivf # ./configure # make && make install 如libevent版本較低，需要在安裝memtier_benchmark前 按以下步驟安裝libevent # wget https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz # tar xfz libevent-2.0.21-stable.tar.gz # pushd libevent-2.0.21-stable # ./configure # make # sudo make install # popd # export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH} 確認安裝成功 # memtier_benchmark --help

3、數據批量裝載

向GaussDB(for Redis) 中裝載數據

使用memtier_benchmark向GaussDB(for Redis) 中裝載數據命令如下，單個value長度1000字節，12個線程，每個線程16個客戶端，每個客戶端發出請求數100000個，全部是寫入操作。

memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 100000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log

可以看到執行了1920萬次操作，平均每秒4.4w的ops，總耗時438秒。

使用redis-cli登錄實例，查看dbsize（注意：由于采用MVCC機制，查詢結果為key數量的預估值，非實時的準確值。）

向原生Redis中裝載數據

為了對比方便，我們在另一臺4核8G的ECS上部署一個單節點的開源Redis，版本與GaussDB(for Redis)一致使用5.0

還是使用memtier_benchmark相同的配置向原始redis中插入數據

memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 6379 -c 16 -t 12 -n 100000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set_2.log

執行一段時間后出現大量報錯

從Redis日志中查看，是在做RDB快照的時候出現了問題。從系統日志中分析當時發生了OOM故障。

這其實和原生Redis的RDB快照處理方式有關，Redis是fork了一個進程使用copy-on-write的方式持久化內存數據，這必然會導致更多內存的申請和使用。并且除了RDB快照，原生redis在執行aof重寫，新加從庫的操作時也會申請使用更多的內存。為了避免OOM的情況出現，操作系統往往要預留出一倍的空閑內存，限制了內存資源的使用率造成極大的浪費。

反觀GaussDB(for Redis) 由于摒棄了fork機制，使得架構更健壯。

從上面的測試也可以看到，導入同樣數量的數據時，GaussDB(for Redis) 的可用性和響應的性能沒有受到任何的影響。

4、實例緊急擴容

為了測試能進行下去，我們將GaussDB(for Redis) 和原生Redis分別擴容到16G。

GaussDB(for Redis)擴容到16G

對GaussDB(for Redis) 來說由于采用了存算分離的架構，分布式存儲池海量在線，按額度分配給用戶使用。擴容過程沒有數據拷貝，也不會影響業務使用。接下來我們測試使用memtier_benchmark在持續的RW操作場景下GaussDB(for Redis)的擴容過程，看看是否會影響業務的讀寫；

memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set_get.log

在執行命令的同時進行擴容操作，查看測試結果和監控發現，擴容期間未見報錯，GaussDB(for Redis) 響應時延沒有明顯變化。

原生Redis擴容到16G

原生Redis實例受服務器內存限制，要擴容到16G只能先升級ECS配置。需要重啟服務器，存在短時間業務不可使用的問題。升級后再次使用memtier_benchmark插入數據依舊報錯，檢查發現還是出現了OOM

沒辦法，只能再次升級云服務器ECS配置到32G，升級期間Redis服務再次不可用。這次升級后終于使用memtier_benchmark成功的插入了數據。

5、數據淘汰問題

下面我們來看高壓力下導致數據寫滿的場景，直觀對比雙方的表現。

插入數據到GaussDB(for Redis)

memtier_benchmark參數設置如下，全部為寫入操作，set的單個value長度50k字節，12個線程，每個線程16個客戶端，每個客戶端發出請求數10000次請求。折算下來 總的插入的key約為192萬，數據量約96G，遠大于實例的規格了。

memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 50000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log

運行了一段時間后，從監控上看到GaussDB(for Redis)磁盤空間100%，并且實例進入只讀模式拒絕新數據的寫入。檢查發現共導入數據194954條。

對于GaussDB(for Redis)來說，當容量接近寫滿的時候，用戶會收到告警通知，此時只需在控制臺點擊“磁盤擴容”，即可秒級完成擴容，對業務沒有影響。

插入數據到原生Redis

原生Redis通過配置限制了內存大小為8G，同樣執行以下命令導入數據

memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 50000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log

運行一段時間后報錯。

登錄redis查看內存已寫滿

也可以通過配置maxmemory-policy設置數據淘汰策略保障數據寫入，如圖我們將淘汰策略設置成allkeys-lru，即淘汰最近最少使用的key 滿足插入數據的內存需求；

修改配置后 插入正常

綜上，GaussDB(for Redis)更加看重數據安全，將“保障用戶數據不丟”作為最高優先級。當數據寫滿后自動進入只讀模式，確保實例中數據的安全。通過控制臺可以做到快速的擴容，最大可能降低對業務的影響。 原生Redis提供了數據淘汰參數，用戶可自主選擇策略當數據寫滿后淘汰符合條件的數據，設計思想更偏向于緩存的用途“數據可隨意丟棄”。如使用在重要的業務場景，不希望數據丟失，建議選擇GaussDB(for Redis)。

6、測試總結

本次我們使用memtier_benchmark分別對GaussDB(for Redis) 和原生Redis進行set操作的測試，8G規格的GaussDB(for Redis) 很順利的完成了數據加載的操作，原生Redis出現OOM異常導致數據加載失敗。原生Redis通過fork進程copy-on-write的方式拷貝數據，在RDB快照、aof重寫以及新增從庫等操作時容易出現OOM異常。反觀GaussDB(for Redis) 由于摒棄了fork機制，使得架構更健壯，服務的可用性更強。

在后續的擴容操作中GaussDB(for Redis)能夠快速完成且對業務RW操作無影響，而原生Redis擴容需停服，期間業務無法正常使用。GaussDB(for Redis)快速擴容的特性非常適合生產環境中需要緊急擴容的場景，如游戲開服、電商搶購的火爆程度遠超預期時。從測試的情況看，擴容幾乎達到了秒級完成，且擴容過程中對業務的讀寫完全沒有影響。

另外更重要的原生Redis無論采用RDB還是aof方式進行數據持久化，都有數據丟失的風險，而GaussDB(for Redis)支持全量數據落盤，GaussDB基礎組件服務提供底層數據三副本冗余保存，能夠保證數據零丟失。

如果使用場景既要滿足KV查詢的高性能，又希望數據得到重視能夠不丟，建議從原生Redis遷移到GaussDB(for Redis) 。

MySQL Redis 云數據庫 GaussDB(for Redis) 數據庫 緩存

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。