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

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

開源不夠，自研頂上

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

注：比較相同數(shù)據(jù)容量（約200G）的成本開銷核算下來，高斯Redis以1/4的價(jià)格擁有10倍以上的可用空間，整體成本相當(dāng)于是開源Redis自建數(shù)據(jù)庫的1/40，這里還不包括自建Redis數(shù)據(jù)庫需要額外的搭建、運(yùn)維、監(jiān)控、升級擴(kuò)容等各項(xiàng)成本。同樣，對比高斯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有兩個(gè)跟業(yè)界完全不一樣的特性，第一個(gè)便是獨(dú)有的存算分離架構(gòu)， 計(jì)算層實(shí)現(xiàn)熱數(shù)據(jù)緩存，存儲層實(shí)現(xiàn)全量數(shù)據(jù)的落盤，中間通過RDMA高速網(wǎng)絡(luò)互連，通過算法預(yù)測用戶的訪問規(guī)律，實(shí)現(xiàn)數(shù)據(jù)的自動(dòng)冷熱交換，最終達(dá)到性能提升。該架構(gòu)基于華為內(nèi)部的自研分布式共享存儲池， 它也是華為全棧數(shù)據(jù)服務(wù)的基石，比如文件EVS、對象存儲OBS、塊存儲，還有數(shù)據(jù)庫族、大數(shù)據(jù)族都依賴于此，可想它的強(qiáng)大及穩(wěn)定性。

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

強(qiáng)一致

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

高可用

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

彈性伸縮

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

高性能

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

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

Geo

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

計(jì)數(shù)

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

即時(shí)通訊

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

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

Feed流

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

推薦系統(tǒng)

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

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

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

最后作為一款KV數(shù)據(jù)庫，高斯Redis即保留了開源Redis的能力，同時(shí)憑借其存算分離的架構(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