第三方測評:GaussDB(for Redis)穩定性與擴容表現

語言: CN / TW / HK
摘要:本文將通過採用Redis Labs推出的多執行緒壓測工具memtier_benchmark對比測試下GaussDB(for Redis) 和原生Redis的特性差異

本文分享自華為雲社群《墨天輪評測:GaussDB(for Redis)穩定性與擴容表現》,本文轉載自墨天輪。

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

GaussDB(for Redis)滿足高讀寫效能場景及容量需彈性擴充套件的業務需求,廣泛使用於電商、遊戲以及影片直播等行業。即可作為前端快取支撐大併發的訪問,也可作為底層資料庫負責核心資料可靠儲存。

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

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) 。

 

點選關注,第一時間瞭解華為雲新鮮技術~