摘要：採用Redis Labs推出的多執行緒壓測工具memtier_benchmark對比測試下GaussDB(for Redis) 和原生Redis的特性差異。
本文分享自華為雲社群《華為雲企業級Redis評測第一期：穩定性與擴容表現》，作者：GaussDB 資料庫 。
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) 。