華為云企業(yè)級(jí)Redis評(píng)測(cè)第一期：穩(wěn)定性與擴(kuò)容表現(xiàn)

GaussDB(for Redis) 是華為云推出的企業(yè)級(jí)Redis，采用計(jì)算存儲(chǔ)分離架構(gòu)，兼容Redis生態(tài)的云原生NoSQL數(shù)據(jù)庫(kù)，基于共享存儲(chǔ)池的多副本強(qiáng)一致機(jī)制，支持持久化存儲(chǔ)，保證數(shù)據(jù)的安全可靠。具有高兼容、高性?xún)r(jià)比、高可靠、彈性伸縮、高可用、無(wú)損擴(kuò)容等特點(diǎn)。GaussDB(for Redis)滿足高讀寫(xiě)性能場(chǎng)景及容量需彈性擴(kuò)展的業(yè)務(wù)需求，廣泛使用于電商、游戲以及視頻直播等行業(yè)。即可作為前端緩存支撐大并發(fā)的訪問(wèn)，也可作為底層數(shù)據(jù)庫(kù)負(fù)責(zé)核心數(shù)據(jù)可靠存儲(chǔ)。

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

目錄導(dǎo)航

1、創(chuàng)建GaussDB(for Redis)實(shí)例

2、安裝memtier_benchmark

3、數(shù)據(jù)批量裝載

向GaussDB(for Redis) 中裝載數(shù)據(jù)

向原生Redis中裝載數(shù)據(jù)

4、實(shí)例緊急擴(kuò)容

GaussDB(for Redis)擴(kuò)容到16G

原生Redis擴(kuò)容到16G

5、數(shù)據(jù)淘汰問(wèn)題

插入數(shù)據(jù)到GaussDB(for Redis)

插入數(shù)據(jù)到原生Redis

6、測(cè)試總結(jié)

1、創(chuàng)建GaussDB(for Redis)實(shí)例

在華為云通過(guò)控制臺(tái)購(gòu)買(mǎi)GaussDB(for Redis)實(shí)例，測(cè)試實(shí)例的配置為8G容量，如下所示。

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

如需更多容量，只需點(diǎn)擊“磁盤(pán)擴(kuò)容”；

如需更高的吞吐性能，則通過(guò)“規(guī)格變更”或“添加節(jié)點(diǎn)”完成。

2、安裝memtier_benchmark

使用與GaussDB(for Redis)測(cè)試實(shí)例相同子網(wǎng)的ECS云服務(wù)器，部署memtier_benchmark測(cè)試環(huán)境

# 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} 確認(rèn)安裝成功 # memtier_benchmark --help

3、數(shù)據(jù)批量裝載

向GaussDB(for Redis) 中裝載數(shù)據(jù)

使用memtier_benchmark向GaussDB(for Redis) 中裝載數(shù)據(jù)命令如下，單個(gè)value長(zhǎng)度1000字節(jié)，12個(gè)線程，每個(gè)線程16個(gè)客戶(hù)端，每個(gè)客戶(hù)端發(fā)出請(qǐng)求數(shù)100000個(gè)，全部是寫(xiě)入操作。

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

可以看到執(zhí)行了1920萬(wàn)次操作，平均每秒4.4w的ops，總耗時(shí)438秒。

使用redis-cli登錄實(shí)例，查看dbsize（注意：由于采用MVCC機(jī)制，查詢(xún)結(jié)果為key數(shù)量的預(yù)估值，非實(shí)時(shí)的準(zhǔn)確值。）

向原生Redis中裝載數(shù)據(jù)

為了對(duì)比方便，我們?cè)诹硪慌_(tái)4核8G的ECS上部署一個(gè)單節(jié)點(diǎn)的開(kāi)源Redis，版本與GaussDB(for Redis)一致使用5.0

還是使用memtier_benchmark相同的配置向原始redis中插入數(shù)據(jù)

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

執(zhí)行一段時(shí)間后出現(xiàn)大量報(bào)錯(cuò)

從Redis日志中查看，是在做RDB快照的時(shí)候出現(xiàn)了問(wèn)題。從系統(tǒng)日志中分析當(dāng)時(shí)發(fā)生了OOM故障。

這其實(shí)和原生Redis的RDB快照處理方式有關(guān)，Redis是fork了一個(gè)進(jìn)程使用copy-on-write的方式持久化內(nèi)存數(shù)據(jù)，這必然會(huì)導(dǎo)致更多內(nèi)存的申請(qǐng)和使用。并且除了RDB快照，原生redis在執(zhí)行aof重寫(xiě)，新加從庫(kù)的操作時(shí)也會(huì)申請(qǐng)使用更多的內(nèi)存。為了避免OOM的情況出現(xiàn)，操作系統(tǒng)往往要預(yù)留出一倍的空閑內(nèi)存，限制了內(nèi)存資源的使用率造成極大的浪費(fèi)。

反觀GaussDB(for Redis) 由于摒棄了fork機(jī)制，使得架構(gòu)更健壯。從上面的測(cè)試也可以看到，導(dǎo)入同樣數(shù)量的數(shù)據(jù)時(shí)，GaussDB(for Redis) 的可用性和響應(yīng)的性能沒(méi)有受到任何的影響。

4、實(shí)例緊急擴(kuò)容

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

GaussDB(for Redis)擴(kuò)容到16G

對(duì)GaussDB(for Redis) 來(lái)說(shuō)由于采用了存算分離的架構(gòu)，分布式存儲(chǔ)池海量在線，按額度分配給用戶(hù)使用。擴(kuò)容過(guò)程沒(méi)有數(shù)據(jù)拷貝，也不會(huì)影響業(yè)務(wù)使用。接下來(lái)我們測(cè)試使用memtier_benchmark在持續(xù)的RW操作場(chǎng)景下GaussDB(for Redis)的擴(kuò)容過(guò)程，看看是否會(huì)影響業(yè)務(wù)的讀寫(xiě)；

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

在執(zhí)行命令的同時(shí)進(jìn)行擴(kuò)容操作，查看測(cè)試結(jié)果和監(jiān)控發(fā)現(xiàn)，擴(kuò)容期間未見(jiàn)報(bào)錯(cuò)，GaussDB(for Redis) 響應(yīng)時(shí)延沒(méi)有明顯變化。

原生Redis擴(kuò)容到16G

原生Redis實(shí)例受服務(wù)器內(nèi)存限制，要擴(kuò)容到16G只能先升級(jí)ECS配置。需要重啟服務(wù)器，存在短時(shí)間業(yè)務(wù)不可使用的問(wèn)題。升級(jí)后再次使用memtier_benchmark插入數(shù)據(jù)依舊報(bào)錯(cuò)，檢查發(fā)現(xiàn)還是出現(xiàn)了OOM

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

5、數(shù)據(jù)淘汰問(wèn)題

下面我們來(lái)看高壓力下導(dǎo)致數(shù)據(jù)寫(xiě)滿的場(chǎng)景，直觀對(duì)比雙方的表現(xiàn)。

插入數(shù)據(jù)到GaussDB(for Redis)

memtier_benchmark參數(shù)設(shè)置如下，全部為寫(xiě)入操作，set的單個(gè)value長(zhǎng)度50k字節(jié)，12個(gè)線程，每個(gè)線程16個(gè)客戶(hù)端，每個(gè)客戶(hù)端發(fā)出請(qǐng)求數(shù)10000次請(qǐng)求。折算下來(lái) 總的插入的key約為192萬(wàn)，數(shù)據(jù)量約96G，遠(yuǎn)大于實(shí)例的規(guī)格了。

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

運(yùn)行了一段時(shí)間后，從監(jiān)控上看到GaussDB(for Redis)磁盤(pán)空間100%，并且實(shí)例進(jìn)入只讀模式拒絕新數(shù)據(jù)的寫(xiě)入。檢查發(fā)現(xiàn)共導(dǎo)入數(shù)據(jù)194954條。

對(duì)于GaussDB(for Redis)來(lái)說(shuō)，當(dāng)容量接近寫(xiě)滿的時(shí)候，用戶(hù)會(huì)收到告警通知，此時(shí)只需在控制臺(tái)點(diǎn)擊“磁盤(pán)擴(kuò)容”，即可秒級(jí)完成擴(kuò)容，對(duì)業(yè)務(wù)沒(méi)有影響。

插入數(shù)據(jù)到原生Redis

原生Redis通過(guò)配置限制了內(nèi)存大小為8G，同樣執(zhí)行以下命令導(dǎo)入數(shù)據(jù)

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

運(yùn)行一段時(shí)間后報(bào)錯(cuò)。

登錄redis查看內(nèi)存已寫(xiě)滿

也可以通過(guò)配置maxmemory-policy設(shè)置數(shù)據(jù)淘汰策略保障數(shù)據(jù)寫(xiě)入，如圖我們將淘汰策略設(shè)置成allkeys-lru，即淘汰最近最少使用的key 滿足插入數(shù)據(jù)的內(nèi)存需求；

修改配置后 插入正常

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

6、測(cè)試總結(jié)

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

在后續(xù)的擴(kuò)容操作中GaussDB(for Redis)能夠快速完成且對(duì)業(yè)務(wù)RW操作無(wú)影響，而原生Redis擴(kuò)容需停服，期間業(yè)務(wù)無(wú)法正常使用。GaussDB(for Redis)快速擴(kuò)容的特性非常適合生產(chǎn)環(huán)境中需要緊急擴(kuò)容的場(chǎng)景，如游戲開(kāi)服、電商搶購(gòu)的火爆程度遠(yuǎn)超預(yù)期時(shí)。從測(cè)試的情況看，擴(kuò)容幾乎達(dá)到了秒級(jí)完成，且擴(kuò)容過(guò)程中對(duì)業(yè)務(wù)的讀寫(xiě)完全沒(méi)有影響。

另外更重要的原生Redis無(wú)論采用RDB還是aof方式進(jìn)行數(shù)據(jù)持久化，都有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，而GaussDB(for Redis)支持全量數(shù)據(jù)落盤(pán)，GaussDB基礎(chǔ)組件服務(wù)提供底層數(shù)據(jù)三副本冗余保存，能夠保證數(shù)據(jù)零丟失。如果使用場(chǎng)景既要滿足KV查詢(xún)的高性能，又希望數(shù)據(jù)得到重視能夠不丟，建議從原生Redis遷移到GaussDB(for Redis) 。

Redis 云數(shù)據(jù)庫(kù) GaussDB(for Redis)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。