點的外賣總能讓離店近的外賣小哥送來，雙11秒殺結束后產品能立刻下架，12306火車票保證從來不超賣，微博下拉就能重繪出好友動態……這些日常碎片的背后都有著Redis的身影，

提起Redis，互聯網從業者無人不知，無人不曉，畢竟，開源Redis作為一款經典的“快取”產品，能支撐眾多業務架構搭建，在游戲、電商、社交媒體等行業中發揮著重要的作用，廣受開發者青睞，

然而近年來，隨著各行業規模逐漸擴大，幾乎只能依附于關系型資料庫的傳統“快取”逐漸難以支撐上層業務，越來越力不從心，

一旦業務規模擴大后資料量逼近記憶體上限，開源Redis輕則發生重要資料逐出，重則導致節點OOM宕機，而且開源Redis為了訪問快速，全部資料都保存在記憶體中，其獨有的fork機制，更讓平時的記憶體使用不得高于50%，使得記憶體價格一直居高不下，導致部署成本非常高，

為了解決這些難題，華為云推出了自研的企業級Key-Value資料庫——云原生分布式資料庫GaussDB(for Redis)（下文簡稱高斯Redis），讓開發者用更低的成本構建依賴快取的應用，且性能更高，運行更穩定，本文將從高斯Redis的技術架構和應用場景出發，一一道來為什么高斯Redis比開源香，以及它是如何做到又快又好的，

開源不夠，自研頂上

開門見山，先看看開發者最關心的性能和成本，如下圖所示，與開源Redis相比，高斯 Redis在成本、可用容量、吞吐、壓縮上都有非常大的優勢：

注：比較相同資料容量（約200G）的成本開銷

核算下來，高斯Redis以1/4的價格擁有10倍以上的可用空間，整體成本相當于是開源Redis自建資料庫的1/40，這里還不包括自建Redis資料庫需要額外的搭建、運維、監控、升級擴容等各項成本，

同樣，對比高斯Redis和開源Redis集群在X86架構下的性能測驗，結果顯示，它能較開源Redis集群能提供更高的QPS，更低的訪問延遲，以及更低的資料存盤成本，

性能優勢：在相同測驗條件下，高斯Redis的QPS較開源Redis集群提高了11%~19%，平均延遲和P99比Redis集群降低了70%以上，p9999比Redis集群降低了15%以上，
抗寫優勢：在資料量大于記憶體的寫測驗中，原生Redis集群因記憶體限制而OOM，高斯Redis依然可以提供不俗的性能服務，它的可用的存盤空間由底層SSD大小決定的，相比原生Redis集群抗寫優勢顯著，
據存盤成本更低：高斯Redis提供了高效的資料壓縮服務，其占用的存盤空間只有開源Redis集群的十分之一，相當于資料存盤成本降低了10倍，

那么，高斯Redis的優勢源自什么？從它的架構中或許可以窺見一斑，

存算分離，突破瓶頸

高斯Redis有兩個跟業界完全不一樣的特性，第一個便是獨有的存算分離架構， 計算層實作熱資料快取，存盤層實作全量資料的落盤，中間通過RDMA高速網路互連，通過演算法預測用戶的訪問規律，實作資料的自動冷熱交換，最終達到性能提升，

該架構基于華為內部的自研分布式共享存盤池， 它也是華為全堆疊資料服務的基石，比如檔案EVS、物件存盤OBS、塊存盤，還有資料庫族、大資料族都依賴于此，可想它的強大及穩定性，

高斯Redis基于共享存盤池實作了一套Shared Everything的云原生架構，充分發揮了云原生的彈性伸縮、資源共享的優勢，使得它具備強一致、秒擴容、低成本、超可用等特性，完美避開了開源Redis的主從堆積、主從不一致、fork抖動、記憶體利用率只有50%、大key阻塞、gossip集群管理等問題，

在存算分離的架構下，高斯Redis的優勢可以總結為：強一致、高可用、彈性伸縮、高性能，

強一致

高斯Redis將全量資料下沉到強一致的共享存盤池，得益于共享存盤池的3副本機制，因此寫入高斯Redis的資料，在客戶端收到回復時，資料也將是3副本強一致的，保證宕機的時候資料不會丟失，從而為業務提供前后一致的狀態，再也不用擔心主從切換后的資料一致性和丟失問題，

高可用

其次是高可用，受益于分布式共享存盤池，高斯Redis的每個計算節點都可以看到并共享所有資料，當某一個計算節點發生故障掛掉，其維護的slot路由資訊，會被剩下的節點自動接管，由于不涉及底層資料的遷移，這個接管程序非常快，所以N個節點下，最多可以容忍掛掉N-1個節點，

彈性伸縮

再就是彈性伸縮帶來的秒擴容能力，實作按需擴容計算和存盤，計算資源的擴容只涉及到元資料的修改，把相應的slot路由資訊遷移到新的節點上，遷移速度非常快，由于采用的共享存盤，大多數情況下存盤擴容只要進行邏輯擴容，不涉及資料的搬遷，在后臺修改存盤配額即可，

高性能

存算分離的架構看似比較重，鏈路比較復雜，實則在硬體采用、軟體優化上，可以做的更大膽更激進，比如RDMA網路、用戶態協議、持久化記憶體等等，因此受益于這些專屬的存盤設備，加上計算層全負荷分擔架構（不引入從節點，因此性能輕松翻倍），對比同類商業資料庫產品，在資料量大于記憶體的存盤場景下，高斯Redis的性能表現很好，另外，對比開源Redis，在資料小于記憶體的點查場景下，高斯性能也有很大優勢，

第二個特性是多模架構帶來的產品使用便捷性，

高斯Redis是多模資料庫Gauss NoSQL的一員，Gauss NoSQL提供了全堆疊的分布式KV引擎、用戶態檔案系統、存盤池等技術，只需要在介面上封裝Redis協議，即可輕松實作一個全新的NoSQL產品，類似的，華為還提供了MongoDB、Cassandra、Influx等NoSQL引擎，

也正是得益于高斯Redis的獨特優勢，使得它在一些典型的應用場景下，能夠應對各種突發情況，最大化發揮出Redis的特性，

互聯網業務神器，支撐海量存盤場景

Redis最常見的應用場景是快取，用來存放秒殺、熱點事件的資料，比如微博熱搜，同時，憑借其優異的存盤能力，快取場景之外的諸多應用Redis也可以輕松應對，比如

流： feed、訊息佇列、IM聊天、IoT心跳上報；

只讀狀態： 歷史訂單、日志審計、歸檔資訊、歷史軌跡、消費記錄、物流詳情；

可變狀態： BI報表、金融風控、智能客服、廣告推薦、標簽工程、用戶畫像、地理位置、路徑規劃、知識圖譜等，

下面，以其中的一些場景為例，具體看看高斯Redis到底有多強大？

Geo

飯點時打開大眾點評查看附近的餐館，外賣小哥根據距離遠近來決定配送的路徑規劃……這些都依靠LBS服務，它的實作又需要Redis來存盤地理位置資料，但開源版本Redis因為記憶體限制，一直沒有大規模應用支持地理位置資訊存盤管理的Geo功能，

高斯Redis使用磁盤替代記憶體，解決了這些難題，它的Geo功能適用于資料量大、讀寫頻繁的場景，可以應對諸如外賣平臺、點評平臺、找房平臺中，隨著用戶增長而對應的地理位置資訊的資料量的增長，最高可達TB級別，以下圖為例，可以看到在高斯Redis支持下，外賣系統可以使用Geo的相關命令，讓用戶獲取騎手的實時位置，騎手也能找到附近可配送的訂單，最終順利將用戶的外賣送到用戶，

計數

社交平臺每條熱搜記錄的搜索量數值；用戶注冊一個帳號后，網站記錄的關注數、粉絲數、動態數；一個介面一分鐘被限制100次請求等，這些資料背后，是一個個計數器在作業，

計數是典型的強一致應用場景，比如電商在秒殺活動中，往往會搭建Redis主從集群給下層MySQL做快取，用Redis的計數器功能抵住流量壓力，

所以如果資料發生不一致，計數器就會得到錯誤的資訊，整個資料庫可能面臨崩潰的危險，但原生Redis的主從同步是異步的，當主節點寫入資料后，從節點不保證立刻更新資料，如果此時讀取資料，讀到的就是過期的舊資料，產生資料不一致問題，高斯Redis則可以把全量資料下沉到強一致共享存盤池，徹底摒棄了開源Redis的異步復制機制，另外，計算層將海量資料進行分片，在故障場景下，自動進行接管，實作了服務的高可用，

即時通訊

即時通訊（簡稱IM）是一個實時通信系統，允許兩人或多人使用網路實時的傳遞文字訊息、檔案、語音與視頻，它最核心的是訊息系統，包括聊天訊息的同步、存盤和檢索，而訊息存盤庫和同步庫又對存盤層的性能有很高的要求：要能支撐海量訊息資料的永久存盤，具備極高的寫入吞吐能力，盡可能低的讀取延遲等等，

綜上，存盤層的性能會直接影響到IM系統的用戶體驗，高斯Redis在性能和規模上可以滿足IM系統對存盤層的嚴格要求，它作為IM系統的存盤層，可以將大量的隨機寫轉換為順序寫，提升資料寫入性能，再通過讀快取、bloom filter優化讀取性能，

下圖是一個基于高斯Redis的IM應用案例，使用的是Stream作為基本資料結構，創建一個群聊時，在Redis中對應地為該群聊創建一個Stream佇列，在發送訊息時，每個用戶都將訊息按照時間順序添加到Stream佇列中，保證了訊息的有序性，

這個應用中涉及到了一種資料型別——Redis Stream，它也是一種訊息佇列，提供訊息的落地存盤功能，讓每個客戶端可以訪問任意時刻的訊息，并記錄訪問位置，保證訊息不會丟失，以IM中的文字聊天為例，使用Stream作為中間件，實作聊天室的發言和資訊查看，高斯Redis可以存盤和處理大規模的Stream資料，魯棒性強的同時成本相對更低，適用于海量訊息佇列的場景，所以，相較于原生Redis，是更為理想的Stream佇列承載方案，

Feed流

互聯網時代，微博、抖音、頭條等都在通過Feed流（資訊流）將關注的好友或感興趣的內容及時推送給用戶，吸參考戶的興趣，提高產品的商業價值，Feed流系統是Feed生成者將生產的Feed經過存盤分發系統傳遞給Feed消費者，最終以某種展現形式，

整個系統最關鍵的是同步存盤系統，首先是內容存盤模塊，由它來存盤最原始的內容，比如用戶發的一條微博；其次是關聯關系存盤模塊，存盤的是用戶之間的關系；最后是信箱模塊，也叫訊息傳遞模塊，通過它將訊息傳遞到每個關聯用戶手中，

在Feed流場景下，高斯Redis能夠支撐海量訊息內容的存盤和低延遲訪問，以及關聯關系的增刪查改，在同步存盤系統中的信箱存盤模塊，高斯Redis的Stream資料結構可以實作佇列能力，實作Feed流訊息讀取，

成為VMALL智能推薦背后的英雄

當電商平臺對AI演算法模型的需求越來越多，特征資料平臺的統一建設是不少開發團隊頭疼的事情，只有通過統一的特征資料存盤，才能改變原有的“資料孤島”，解決生產重復造輪子的窘境，

華為商城（VMALL）就有這樣的困擾，VMALL使用了大量的AI和大資料技術，用來支撐智能推薦、精準營銷、智能搜索、選品投放等業務的高效開展，但因為特征資料準備階段缺乏通用平臺，嚴重影響研發效率，

特征資料庫需要承擔打通線上/線下多個場景，對接批式/流式多種資料源，滿足訓練/推理多樣消費需求，相應地對存盤也提出了高要求：既能提供低成本的海量資料存盤并方便擴容， 又能保證資料的絕對可靠和服務的高可用；既要滿足低時延的線上推理，又要滿足高吞吐的線下訓練； 既能提供簡潔的KV介面供下游輕松消費，又要兼容主流的批式/流式處理引擎（Spark/Flink等）供上游快速接入，

為了滿足這些要求，深入調研后，VMALL大資料團隊最終選擇了高斯Redis作為特征資料庫，

在線上推理的特征生產（抽取、處理、存盤）中，特征平臺會定時調度Spark作業，從各種資料倉庫、資料湖中提取資料，進行特征工程處理后，存入高斯Redis，至于實時特征，則由Flink消費Kafka，或流式存盤中的資料，持續更新到高斯Redis中，

在特征消費的推理環節，對于使用實時特征的場景（如實時推薦系統），由Flink從Kafka中實時取得用戶請求記錄，并從高斯Redis查詢取得特征，將記錄和特征拼接成訓練樣本，存盤到檔案中，供線下訓練使用，

目前VMALL已完成一期的特征資料遷移，包括“特征生產”業務中的“Spark離線特征生產”，以及“特征消費”業務中的“線下訓練Flink特征查詢”，遷移后的運行結果顯示，高斯Redis在業務高峰時段時延穩定，能夠滿足VMALL當前業務要求，其中，讀平均時延0.2ms（p99<0.4ms），寫入平均時延0.6ms（P99<2ms），

費用方面，按照VMALL的特征體量測算，億級用戶，每個用戶的特征數量是數K-數10K，高斯Redis一年的費用僅3W出頭，如果選用社區Redis，費用在20W+，

綜上，高斯Redis在VMALL特征工程平臺建設中，起到了關鍵作用，它在成本，可靠性，可擴展性等方面具有優勢，可作為特征資料存盤的理想方案，提供企業級的穩定可靠的Redis服務能力，

最后

作為一款KV資料庫，高斯Redis即保留了開源Redis的能力，同時憑借其存算分離的架構，在成本、穩定性、可靠性、一致性等方面做出了新的突破，它也更加適用于當下資料規模龐大的互聯網業務，包括電商平臺的秒殺、推薦系統、社交平臺的資訊流等等，本文只是簡單地解讀了高斯Redis的幾個典型特性，更多技術細節，以及應用案例、遷移指南等可以查看【大廠內參】第12期：技術架構+應用場景揭秘，為什么高斯Redis比開源香？-云社區-華為云 (huaweicloud.com)

本文由華為云發布，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/449768.html

標籤：其他

上一篇：pikachu安裝教程（windows）

下一篇：藍橋杯試題集