摘要：采用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的特性差異。
在華為雲通過控制台購買GaussDB(for Redis)執行個體，測試執行個體的配置為8G容量，如下所示。
如截圖所示，GaussDB(for Redis)提供了統一的負載均衡位址和端口，友善應用程式通路高可用的Redis服務。持久化資料存儲空間直覺展示了資料量及容量上限。另外，依托于GaussDB(for Redis)存算分離的架構，執行個體的容量和性能可以按需分别擴充：
如需更多容量，隻需點選“磁盤擴容”；
如需更高的吞吐性能，則通過“規格變更”或“添加節點”完成。
使用與GaussDB(for Redis)測試執行個體相同子網的ECS雲伺服器，部署memtier_benchmark測試環境
使用memtier_benchmark向GaussDB(for Redis) 中裝載資料指令如下，單個value長度1000位元組，12個線程，每個線程16個用戶端，每個用戶端送出請求數100000個，全部是寫入操作。
使用redis-cli登入執行個體，檢視dbsize（注意：由于采用MVCC機制，查詢結果為key數量的預估值，非實時的準确值。）
為了對比友善，我們在另一台4核8G的ECS上部署一個單節點的開源Redis，版本與GaussDB(for Redis)一緻使用5.0
還是使用memtier_benchmark相同的配置向原始redis中插入資料
從Redis日志中檢視，是在做RDB快照的時候出現了問題。從系統日志中分析當時發生了OOM故障。
這其實和原生Redis的RDB快照處理方式有關，Redis是fork了一個程序使用copy-on-write的方式持久化記憶體資料，這必然會導緻更多記憶體的申請和使用。并且除了RDB快照，原生redis在執行aof重寫，新加從庫的操作時也會申請使用更多的記憶體。為了避免OOM的情況出現，作業系統往往要預留出一倍的空閑記憶體，限制了記憶體資源的使用率造成極大的浪費。
反觀GaussDB(for Redis) 由于摒棄了fork機制，使得架構更健壯。從上面的測試也可以看到，導入同樣數量的資料時，GaussDB(for Redis) 的可用性和響應的性能沒有受到任何的影響。
為了測試能進行下去，我們将GaussDB(for Redis) 和原生Redis分别擴容到16G。
對GaussDB(for Redis) 來說由于采用了存算分離的架構，分布式存儲池海量線上，按額度配置設定給使用者使用。擴容過程沒有資料拷貝，也不會影響業務使用。接下來我們測試使用memtier_benchmark在持續的RW操作場景下GaussDB(for Redis)的擴容過程，看看是否會影響業務的讀寫；
原生Redis執行個體受伺服器記憶體限制，要擴容到16G隻能先更新ECS配置。需要重新開機伺服器，存在短時間業務不可使用的問題。更新後再次使用memtier_benchmark插入資料依舊報錯，檢查發現還是出現了OOM
沒辦法，隻能再次更新雲伺服器ECS配置到32G，更新期間Redis服務再次不可用。這次更新後終于使用memtier_benchmark成功的插入了資料。
下面我們來看高壓力下導緻資料寫滿的場景，直覺對比雙方的表現。
memtier_benchmark參數設定如下，全部為寫入操作，set的單個value長度50k位元組，12個線程，每個線程16個用戶端，每個用戶端送出請求數10000次請求。折算下來 總的插入的key約為192萬，資料量約96G，遠大于執行個體的規格了。
對于GaussDB(for Redis)來說，當容量接近寫滿的時候，使用者會收到告警通知，此時隻需在控制台點選“磁盤擴容”，即可秒級完成擴容，對業務沒有影響。
原生Redis通過配置限制了記憶體大小為8G，同樣執行以下指令導入資料
登入redis檢視記憶體已寫滿
也可以通過配置maxmemory-policy設定資料淘汰政策保障資料寫入，如圖我們将淘汰政策設定成allkeys-lru，即淘汰最近最少使用的key 滿足插入資料的記憶體需求；
修改配置後 插入正常
綜上，GaussDB(for Redis)更加看重資料安全，将“保障使用者資料不丢”作為最高優先級。當資料寫滿後自動進入隻讀模式，確定執行個體中資料的安全。通過控制台可以做到快速的擴容，最大可能降低對業務的影響。 原生Redis提供了資料淘汰參數，使用者可自主選擇政策當資料寫滿後淘汰符合條件的資料，設計思想更偏向于緩存的用途“資料可随意丢棄”。如使用在重要的業務場景，不希望資料丢失，建議選擇GaussDB(for Redis)。
本次我們使用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) 。
點選關注，第一時間了解華為雲新鮮技術~