摘要：本文將通過採用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) 。