華為云推出自研企業(yè)級Key-Value數(shù)據(jù)庫 提供企業(yè)級的穩(wěn)定可靠的Redis服務(wù)能力

點的外賣總能讓離店近的外賣小哥送來，雙11秒殺結(jié)束后產(chǎn)品能立刻下架，12306火車票保證從來不超賣，微博下拉就能刷新出好友動態(tài)……這些日常碎片的背后都有著Redis的身影。提起Redis，互聯(lián)網(wǎng)從業(yè)者無人不知，無人不曉。畢竟，開源Redis作為一款經(jīng)典的“緩存”產(chǎn)品，能支撐眾多業(yè)務(wù)架構(gòu)搭建，在游戲、電商、社交媒體等行業(yè)中發(fā)揮著重要的作用，廣受開發(fā)者青睞。然而近年來，隨著各行業(yè)規(guī)模逐漸擴大，幾乎只能依附于關(guān)系型數(shù)據(jù)庫的傳統(tǒng)“緩存”逐漸難以支撐上層業(yè)務(wù)，越來越力不從心。一旦業(yè)務(wù)規(guī)模擴大后數(shù)據(jù)量逼近內(nèi)存上線，開源Redis輕則發(fā)生重要數(shù)據(jù)逐出，重則導(dǎo)致節(jié)點OOM宕機。而且開源Redis為了訪問快速，全部數(shù)據(jù)都保存在內(nèi)存中，其獨有的fork機制，更讓平時的內(nèi)存使用不得高于50%，使得內(nèi)存價格一直居高不下，導(dǎo)致部署成本非常高。為了解決這些難題，華為云推出了自研的企業(yè)級Key-Value數(shù)據(jù)庫——云原生分布式數(shù)據(jù)庫GaussDB（for Redis）（下文簡稱高斯Redis），讓開發(fā)者用更低的成本構(gòu)建依賴緩存的應(yīng)用，且性能更高，運行更穩(wěn)定。本文將從高斯Redis的技術(shù)架構(gòu)和應(yīng)用場景出發(fā)，一一道來為什么高斯Redis比開源香，以及它是如何做到又快又好的。

開源不夠，自研頂上

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

注：比較相同數(shù)據(jù)容量（約200G）的成本開銷核算下來，高斯Redis以1/4的價格擁有10倍以上的可用空間，整體成本相當(dāng)于是開源Redis自建數(shù)據(jù)庫的1/40，這里還不包括自建Redis數(shù)據(jù)庫需要額外的搭建、運維、監(jiān)控、升級擴容等各項成本。同樣，對比高斯Redis和開源Redis集群在X86架構(gòu)下的性能測試，結(jié)果顯示，它能較開源Redis集群能提供更高的QPS，更低的訪問延遲，以及更低的數(shù)據(jù)存儲成本。

性能優(yōu)勢：在相同測試條件下，高斯Redis的QPS較開源Redis集群提高了11%~19%，平均延遲和P99比Redis集群降低了70%以上，p9999比Redis集群降低了15%以上。

抗寫優(yōu)勢：在數(shù)據(jù)量大于內(nèi)存的寫測試中，原生Redis集群因內(nèi)存限制而OOM，高斯Redis依然可以提供不俗的性能服務(wù)，它的可用的存儲空間由底層SSD大小決定的，相比原生Redis集群抗寫優(yōu)勢顯著。

數(shù)據(jù)存儲成本更低：高斯Redis提供了高效的數(shù)據(jù)壓縮服務(wù)，其占用的存儲空間只有開源Redis集群的十分之一，相當(dāng)于數(shù)據(jù)存儲成本降低了10倍。

那么，高斯Redis的優(yōu)勢源自什么？從它的架構(gòu)中或許可以窺見一斑。

存算分離，突破瓶頸 高斯Redis有兩個跟業(yè)界完全不一樣的特性，第一個便是獨有的存算分離架構(gòu)， 計算層實現(xiàn)熱數(shù)據(jù)緩存，存儲層實現(xiàn)全量數(shù)據(jù)的落盤，中間通過RDMA高速網(wǎng)絡(luò)互連，通過算法預(yù)測用戶的訪問規(guī)律，實現(xiàn)數(shù)據(jù)的自動冷熱交換，最終達到性能提升。該架構(gòu)基于華為內(nèi)部的自研分布式共享存儲池， 它也是華為全棧數(shù)據(jù)服務(wù)的基石，比如文件EVS、對象存儲OBS、塊存儲，還有數(shù)據(jù)庫族、大數(shù)據(jù)族都依賴于此，可想它的強大及穩(wěn)定性。

高斯Redis基于共享存儲池實現(xiàn)了一套Shared Everything的云原生架構(gòu)，充分發(fā)揮了云原生的彈性伸縮、資源共享的優(yōu)勢，使得它具備強一致、秒擴容、低成本、超可用等特性，完美避開了開源Redis的主從堆積、主從不一致、fork抖動、內(nèi)存利用率只有50%、大key阻塞、gossip集群管理等問題。在存算分離的架構(gòu)下，高斯Redis的優(yōu)勢可以總結(jié)為：強一致、高可用、彈性伸縮、高性能。

強一致

高斯Redis將全量數(shù)據(jù)下沉到強一致的共享存儲池，得益于共享存儲池的3副本機制，因此寫入高斯Redis的數(shù)據(jù)，在客戶端收到回復(fù)時，數(shù)據(jù)也將是3副本強一致的，保證宕機的時候數(shù)據(jù)不會丟失，從而為業(yè)務(wù)提供前后一致的狀態(tài)，再也不用擔(dān)心主從切換后的數(shù)據(jù)一致性和丟失問題。

高可用

其次是高可用，受益于分布式共享存儲池，高斯Redis的每個計算節(jié)點都可以看到并共享所有數(shù)據(jù)，當(dāng)某一個計算節(jié)點發(fā)生故障掛掉，其維護的slot路由信息，會被剩下的節(jié)點自動接管。由于不涉及底層數(shù)據(jù)的遷移，這個接管過程非?？?。所以N個節(jié)點下，最多可以容忍掛掉N-1個節(jié)點。

彈性伸縮

再就是彈性伸縮帶來的秒擴容能力，實現(xiàn)按需擴容計算和存儲。計算資源的擴容只涉及到元數(shù)據(jù)的修改，把相應(yīng)的slot路由信息遷移到新的節(jié)點上，遷移速度非?？臁Ｓ捎诓捎玫墓蚕泶鎯?，大多數(shù)情況下存儲擴容只要進行邏輯擴容，不涉及數(shù)據(jù)的搬遷，在后臺修改存儲配額即可。

高性能

存算分離的架構(gòu)看似比較重，鏈路比較復(fù)雜，實則在硬件采用、軟件優(yōu)化上，可以做的更大膽更激進，比如RDMA網(wǎng)絡(luò)、用戶態(tài)協(xié)議、持久化內(nèi)存等等。因此受益于這些專屬的存儲設(shè)備，加上計算層全負(fù)荷分擔(dān)架構(gòu)（不引入從節(jié)點，因此性能輕松翻倍），對比同類商業(yè)數(shù)據(jù)庫產(chǎn)品，在數(shù)據(jù)量大于內(nèi)存的存儲場景下，高斯Redis的性能表現(xiàn)很好。另外，對比開源Redis，在數(shù)據(jù)小于內(nèi)存的點查場景下，高斯性能也有很大優(yōu)勢。第二個特性是多模架構(gòu)帶來的產(chǎn)品使用便捷性。高斯Redis是多模數(shù)據(jù)庫Gauss NoSQL的一員，Gauss NoSQL提供了全棧的分布式KV引擎、用戶態(tài)文件系統(tǒng)、存儲池等技術(shù)，只需要在接口上封裝Redis協(xié)議，即可輕松實現(xiàn)一個全新的NoSQL產(chǎn)品。類似的，華為還提供了MongoDB、Cassandra、Influx等NoSQL引擎。也正是得益于高斯Redis的獨特優(yōu)勢，使得它在一些典型的應(yīng)用場景下，能夠應(yīng)對各種突發(fā)情況，最大化發(fā)揮出Redis的特性。

互聯(lián)網(wǎng)業(yè)務(wù)神器，支撐海量存儲場景 Redis最常見的應(yīng)用場景是緩存，用來存放秒殺、熱點事件的數(shù)據(jù)，比如微博熱搜。同時，憑借其優(yōu)異的存儲能力，緩存場景之外的諸多應(yīng)用Redis也可以輕松應(yīng)對，比如：流：feed、消息隊列、IM聊天、IoT心跳上報；只讀狀態(tài)： 歷史訂單、日志審計、歸檔信息、歷史軌跡、消費記錄、物流詳情；可變狀態(tài)：BI報表、金融風(fēng)控、智能客服、廣告推薦、標(biāo)簽工程、用戶畫像、地理位置、路徑規(guī)劃、知識圖譜等。下面，以其中的一些場景為例，具體看看高斯Redis到底有多強大？

Geo

飯點時打開大眾點評查看附近的餐館，外賣小哥根據(jù)距離遠近來決定配送的路徑規(guī)劃……這些都依靠LBS服務(wù)，它的實現(xiàn)又需要Redis來存儲地理位置數(shù)據(jù)。但開源版本Redis因為內(nèi)存限制，一直沒有大規(guī)模應(yīng)用支持地理位置信息存儲管理的Geo功能。高斯Redis使用磁盤替代內(nèi)存，解決了這些難題，它的Geo功能適用于數(shù)據(jù)量大、讀寫頻繁的場景，可以應(yīng)對諸如外賣平臺、點評平臺、找房平臺中，隨著用戶增長而對應(yīng)的地理位置信息的數(shù)據(jù)量的增長，最高可達TB級別。以下圖為例，可以看到在高斯Redis支持下，外賣系統(tǒng)可以使用Geo的相關(guān)命令，讓用戶獲取騎手的實時位置，騎手也能找到附近可配送的訂單，最終順利將用戶的外賣送到用戶。

計數(shù)

社交平臺每條熱搜記錄的搜索量數(shù)值；用戶注冊一個帳號后，網(wǎng)站記錄的關(guān)注數(shù)、粉絲數(shù)、動態(tài)數(shù)；一個接口一分鐘被限制100次請求等。這些數(shù)據(jù)背后，是一個個計數(shù)器在工作。計數(shù)是典型的強一致應(yīng)用場景，比如電商在秒殺活動中，往往會搭建Redis主從集群給下層MySQL做緩存，用Redis的計數(shù)器功能抵住流量壓力。所以如果數(shù)據(jù)發(fā)生不一致，計數(shù)器就會得到錯誤的信息，整個數(shù)據(jù)庫可能面臨崩潰的危險。但原生Redis的主從同步是異步的，當(dāng)主節(jié)點寫入數(shù)據(jù)后，從節(jié)點不保證立刻更新數(shù)據(jù)，如果此時讀取數(shù)據(jù)，讀到的就是過期的舊數(shù)據(jù)，產(chǎn)生數(shù)據(jù)不一致問題。高斯Redis則可以把全量數(shù)據(jù)下沉到強一致共享存儲池，徹底摒棄了開源Redis的異步復(fù)制機制。另外，計算層將海量數(shù)據(jù)進行分片，在故障場景下，自動進行接管，實現(xiàn)了服務(wù)的高可用。

即時通訊

即時通訊（簡稱IM）是一個實時通信系統(tǒng)，允許兩人或多人使用網(wǎng)絡(luò)實時的傳遞文字消息、文件、語音與視頻。它最核心的是消息系統(tǒng)，包括聊天消息的同步、存儲和檢索。而消息存儲庫和同步庫又對存儲層的性能有很高的要求：要能支撐海量消息數(shù)據(jù)的永久存儲，具備極高的寫入吞吐能力，盡可能低的讀取延遲等等。綜上，存儲層的性能會直接影響到IM系統(tǒng)的用戶體驗。高斯Redis在性能和規(guī)模上可以滿足IM系統(tǒng)對存儲層的嚴(yán)格要求，它作為IM系統(tǒng)的存儲層，可以將大量的隨機寫轉(zhuǎn)換為順序?qū)懀嵘龜?shù)據(jù)寫入性能，再通過讀緩存、bloom filter優(yōu)化讀取性能。下圖是一個基于高斯Redis的IM應(yīng)用案例，使用的是Stream作為基本數(shù)據(jù)結(jié)構(gòu)。創(chuàng)建一個群聊時，在Redis中對應(yīng)地為該群聊創(chuàng)建一個Stream隊列。在發(fā)送消息時，每個用戶都將消息按照時間順序添加到Stream隊列中，保證了消息的有序性。

這個應(yīng)用中涉及到了一種數(shù)據(jù)類型——Redis Stream，它也是一種消息隊列，提供消息的落地存儲功能，讓每個客戶端可以訪問任意時刻的消息，并記錄訪問位置，保證消息不會丟失，以IM中的文字聊天為例，使用Stream作為中間件，實現(xiàn)聊天室的發(fā)言和信息查看。高斯Redis可以存儲和處理大規(guī)模的Stream數(shù)據(jù)，魯棒性強的同時成本相對更低，適用于海量消息隊列的場景。所以，相較于原生Redis，是更為理想的Stream隊列承載方案。

Feed流

互聯(lián)網(wǎng)時代，微博、抖音、頭條等都在通過Feed流（信息流）將關(guān)注的好友或感興趣的內(nèi)容及時推送給用戶，吸引用戶的興趣，提高產(chǎn)品的商業(yè)價值。Feed流系統(tǒng)是Feed生成者將生產(chǎn)的Feed經(jīng)過存儲分發(fā)系統(tǒng)傳遞給Feed消費者，最終以某種展現(xiàn)形式。整個系統(tǒng)最關(guān)鍵的是同步存儲系統(tǒng)，首先是內(nèi)容存儲模塊，由它來存儲最原始的內(nèi)容，比如用戶發(fā)的一條微博；其次是關(guān)聯(lián)關(guān)系存儲模塊，存儲的是用戶之間的關(guān)系；最后是信箱模塊，也叫消息傳遞模塊 ，通過它將消息傳遞到每個關(guān)聯(lián)用戶手中。在Feed流場景下，高斯Redis能夠支撐海量消息內(nèi)容的存儲和低延遲訪問，以及關(guān)聯(lián)關(guān)系的增刪查改。在同步存儲系統(tǒng)中的信箱存儲模塊，高斯Redis的Stream數(shù)據(jù)結(jié)構(gòu)可以實現(xiàn)隊列能力，實現(xiàn)Feed流消息讀取。

推薦系統(tǒng)

電商、社交等領(lǐng)域的推薦系統(tǒng)非常發(fā)達，追溯其背后技術(shù)，不外乎這三個環(huán)節(jié)：分布式計算、特征存儲、推薦算法。其中，特征數(shù)據(jù)的存儲起到關(guān)鍵的銜接作用，由于KV形式的數(shù)據(jù)抽象與特征數(shù)據(jù)極為接近，因此推薦系統(tǒng)里往往少不了Redis的身影。由于開源Redis在大數(shù)據(jù)場景下的一些固有痛點，高斯Redis是不少客戶首選的數(shù)據(jù)庫選型。由高斯Redis負(fù)責(zé)核心的特征數(shù)據(jù)存儲，提供穩(wěn)定、可靠的KV存儲能力。加上它的高性能持久化技術(shù)和細(xì)粒度存儲池，可幫助企業(yè)將數(shù)據(jù)庫使用成本降低75%以上。高斯Redis獨特的多線程設(shè)計和全部節(jié)點可寫，抗寫能力強，可從容應(yīng)對Spark灌庫壓力和實時更新。而且因為高斯Redis完全兼容Redis協(xié)議，即開即用，用戶可使用熟悉的Spark SQL語法輕松訪問，完成特征數(shù)據(jù)灌庫、更新、提取等關(guān)鍵任務(wù)。與此同時，數(shù)據(jù)源經(jīng)過Flink加工后，也可輕松存入高斯Redis中。

成為VMALL智能推薦背后的英雄 當(dāng)電商平臺對AI算法模型的需求越來越多，特征數(shù)據(jù)平臺的統(tǒng)一建設(shè)是不少開發(fā)團隊頭疼的事情。只有通過統(tǒng)一的特征數(shù)據(jù)存儲，才能改變原有的“數(shù)據(jù)孤島”，解決生產(chǎn)重復(fù)造輪子的窘境。華為商城（VMALL）就有這樣的困擾，VMALL使用了大量的AI和大數(shù)據(jù)技術(shù)，用來支撐智能推薦、精準(zhǔn)營銷、智能搜索、選品投放等業(yè)務(wù)的高效開展。但因為特征數(shù)據(jù)準(zhǔn)備階段缺乏通用平臺，嚴(yán)重影響研發(fā)效率。特征數(shù)據(jù)庫需要承擔(dān)打通線上/線下多個場景，對接批式/流式多種數(shù)據(jù)源，滿足訓(xùn)練/推理多樣消費需求，相應(yīng)地對存儲也提出了高要求：既能提供低成本的海量數(shù)據(jù)存儲并方便擴容， 又能保證數(shù)據(jù)的絕對可靠和服務(wù)的高可用；既要滿足低時延的線上推理，又要滿足高吞吐的線下訓(xùn)練； 既能提供簡潔的KV接口供下游輕松消費，又要兼容主流的批式/流式處理引擎（Spark/Flink等）供上游快速接入。為了滿足這些要求，深入調(diào)研后，VMALL大數(shù)據(jù)團隊最終選擇了高斯Redis作為特征數(shù)據(jù)庫。

在線上推理的特征生產(chǎn)（抽取、處理、存儲）中，特征平臺會定時調(diào)度Spark作業(yè)，從各種數(shù)據(jù)倉庫、數(shù)據(jù)湖中提取數(shù)據(jù)，進行特征工程處理后，存入高斯Redis。至于實時特征，則由Flink消費Kafka，或流式存儲中的數(shù)據(jù)，持續(xù)更新到高斯Redis中。在特征消費的推理環(huán)節(jié)，對于使用實時特征的場景（如實時推薦系統(tǒng)），由Flink從Kafka中實時取得用戶請求記錄，并從高斯Redis查詢?nèi)〉锰卣?，將記錄和特征拼接成?xùn)練樣本，存儲到文件中，供線下訓(xùn)練使用。目前VMALL已完成一期的特征數(shù)據(jù)遷移，包括“特征生產(chǎn)”業(yè)務(wù)中的“Spark離線特征生產(chǎn)”，以及“特征消費”業(yè)務(wù)中的“線下訓(xùn)練Flink特征查詢”。遷移后的運行結(jié)果顯示，高斯Redis在業(yè)務(wù)高峰時段時延穩(wěn)定，能夠滿足VMALL當(dāng)前業(yè)務(wù)要求。其中，讀平均時延0.2ms（p99《0.4ms），寫入平均時延0.6ms（P99《2ms）。費用方面，按照VMALL的特征體量測算，億級用戶，每個用戶的特征數(shù)量是數(shù)K-數(shù)10K，高斯Redis一年的費用僅3W出頭，如果選用社區(qū)Redis，費用在20W+。綜上，高斯Redis在VMALL特征工程平臺建設(shè)中，起到了關(guān)鍵作用。它在成本，可靠性，可擴展性等方面具有優(yōu)勢，可作為特征數(shù)據(jù)存儲的理想方案，提供企業(yè)級的穩(wěn)定可靠的Redis服務(wù)能力。

最后作為一款KV數(shù)據(jù)庫，高斯Redis即保留了開源Redis的能力，同時憑借其存算分離的架構(gòu)，在成本、穩(wěn)定性、可靠性、一致性等方面做出了新的突破，它也更加適用于當(dāng)下數(shù)據(jù)規(guī)模龐大的互聯(lián)網(wǎng)業(yè)務(wù)，包括電商平臺的秒殺、推薦系統(tǒng)、社交平臺的信息流等等。

原文標(biāo)題：【大廠內(nèi)參】技術(shù)架構(gòu)+應(yīng)用場景揭秘，為什么高斯Redis比開源香？

文章出處：【微信公眾號：華為開發(fā)者社區(qū)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
責(zé)任編輯:pj