【云駐共創(chuàng)】從相識到相惜：Redis與計算存儲分離四部曲

近期全國兩會正在轟轟烈烈的召開，各人大代表也基于自己的一些實踐提出了自己的意見，例如“出臺手機設(shè)備適老標準”、“老師獎勵不與升學(xué)率掛鉤”、“提高留學(xué)生招生標準”等等。這些問題必不可少地引來了網(wǎng)上用戶的各種討論聲音，你甚至可以想象出網(wǎng)上用戶深夜在努力敲鍵盤的樣子……

當然，我們今天來不是來講全國兩會的。我們技術(shù)人，技術(shù)魂，要講的是這“網(wǎng)上討論的聲音”背后的技術(shù)——Redis。現(xiàn)如今我們網(wǎng)上聊天已經(jīng)是家常便飯了，那么你有沒有意識到，在我們聊天的背后，其實是有一個非常復(fù)雜的聊天系統(tǒng)的呢？在這復(fù)雜的聊天系統(tǒng)中的消息推送功能，更是其非常重要的一個模塊。一般來說，消息推送，是采用Redis的歷史數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)的。這個功能的簡單運用，就是用戶可以通過歷史的順序查找，實現(xiàn)查看歷史消息的功能。

與Redis相遇

相信到這里，大家對Redis的功能強大已經(jīng)有一定認知了。那么我們來正式介紹一下Redis：Redis（Remote Dictionary Server )，即遠程字典服務(wù)，是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。Redis本身有三個優(yōu)點：快、穩(wěn)、準，也就是時延低、性能好、數(shù)據(jù)結(jié)構(gòu)豐富。如此強大的Redis，是“電商秒殺”等業(yè)務(wù)場景中的“熟客”：將秒殺商品的庫存數(shù)量存入Redis，通過Redis來提供一個全局庫存的實時扣減和查詢服務(wù)。

但是，沒有任何技術(shù)是完美無瑕的，Redis亦如此。Redis本身有幾個缺點：

Redis的bgsave影響性能；

Redis的集群管理的一致性非常弱；

Redis的內(nèi)存限制了它的存儲容量

Redis的內(nèi)存利用率只有一半；

Redis沒有冷熱分離機制。

以上都是Redis的一些缺點，是不是看完覺得Redis又被“拉下神壇”，不如不用了？不要放棄，針對開源Redis的這些缺點，華為云數(shù)據(jù)庫團隊，做了“億點”努力！

與GaussDB（for Redis）相識

經(jīng)過千難萬險，千辛萬苦，千錘百煉，華為云自研出了一款全新的Redis數(shù)據(jù)庫，也即是GaussDB ( for Redis )！！！

華為云的自研Redis源自于GaussDB，采用了最先進的計算存儲分離架構(gòu)和多模架構(gòu)——屬于業(yè)界首創(chuàng)。而GaussDB，則是華為云數(shù)據(jù)庫的亮點品牌，是華為云引以為傲的數(shù)據(jù)庫架構(gòu)。

針對華為云的GaussDB，我們來做一個簡單的介紹吧（架構(gòu)圖如下）：其是基于DFV架構(gòu)來構(gòu)建的。而DFV則是華為內(nèi)部自研的超級DataLake（分布式存儲池），可用于構(gòu)建全棧數(shù)據(jù)服務(wù)架構(gòu)，比如存儲部分支持FusionStorage、云盤ECS、對象存儲OBS，數(shù)據(jù)庫部分支持的NoSQL、OLTP，大數(shù)據(jù)部分則支持HDFS的生態(tài)、Hadoop、Hbase、Hive等等。

通過下圖可以看到，在上層的數(shù)據(jù)服務(wù)和下層的存儲之間，是通過RDMA的高性能網(wǎng)絡(luò)來連接，從而能夠起到一個降低時延的作用。作為最底下的存儲層，被分成了不同的存儲介質(zhì)，如SCM、NVMe SSD、HDD、眾核/多核等等。不同的存儲介質(zhì)是用來滿足不同的服務(wù)對于性能的不同的需求的。

這里可以看出，其實GaussDB NoSQL就是一套成熟的DFV架構(gòu)，也是集華為整個公司的力量去構(gòu)建的一個架構(gòu)最后孵化出的一個產(chǎn)品。其背后的心血、可用性，以及價值，都是難以估量的。

OK，我們再來看看NoSQL的“全家福”（見下圖）。可以看到，下圖已經(jīng)囊括了NoSQL的全棧的數(shù)據(jù)庫，包括Redis、Influx、Cassandra、Mongo在內(nèi)，都是基于GaussDB相同的架構(gòu)去實現(xiàn)的。

拆解來看，這整套架構(gòu)分為三個層次，從上往下分別是：

服務(wù)層（Service Layer），主要負責數(shù)據(jù)庫的協(xié)議的解析、處理、執(zhí)行以及回包等等；

索引層（Index Layer），主要負責中間的路由及元數(shù)據(jù)管理等等；

持續(xù)化存儲層（Persistent Layer），也即是DFV POOL。

當然，我們今天不會把每個部分都進行講解，而是要對其中的Redis進行更深入的講解，其所擁有的強一致、秒擴容、超可用、低成本這四個特點，讓它成為了“家族中最靚的仔”。我們來一步步深入了解一下它吧。

與GaussDB （for Redis）相知

在對Redis的四個特性進行深一步講解之前，我們先對GaussDB ( for Redis )有一個全面的認識吧。從架構(gòu)設(shè)計上（見下圖）：

設(shè)計了中心化的咨詢管理--ConfigureSever（cfgsvr）：也就說用它來避免的就是社區(qū)Redis在集群管理上弱一致的一些問題；

設(shè)計了proxy的接入方式：讓一些非class的用戶通過這個proxy接入；

設(shè)計了Slot的數(shù)據(jù)管理：在最底層的ShardServer，設(shè)計Slot的數(shù)據(jù)管理。是說每一個項目Server會分別負責不同的Slot，每個Slot又對應(yīng)不同的數(shù)據(jù)，最終的數(shù)據(jù)實際上都是落在最底層的分布式共享存儲池（DFV POOL）上。

到這里，相信大家對GaussDB ( for Redis )的架構(gòu)和性能已經(jīng)有了一定的印象，那么我們便來詳細介紹它的硬實力吧！

硬實力一：強一致

一提到“強一致”，很多業(yè)務(wù)開發(fā)人員會潛意識認為是一個比較高（fu）級（za）的技術(shù)，但是對他/她自身的業(yè)務(wù)邏輯，甚至他/她自身代碼能力的提高，其實沒有任何幫助。他們會說，“我不需要強一致啊”，或者，“強一致跟我沒有關(guān)系”。

但我們聽聽業(yè)界大牛對此的看法：強一致不僅僅是一個技術(shù)需求，實際上它也是一個業(yè)務(wù)需求。我們?nèi)绾稳ダ斫膺@句話呢？我們來舉個栗子：三八婦女節(jié)剛剛過去，在這個無論大大小小的節(jié)日，都要被蹭一波流量的時代，當然少不了電商們的促銷活動。電商們在做促銷活動的時候，整個平臺的流量是非常大的，但是整個系統(tǒng)能夠抗住的壓力又非常有限，這個矛盾要怎么解決呢？這里依賴的就是Redis的計數(shù)器，來構(gòu)建的一個非常精巧的限流機制。

硬件不夠，軟件來湊。這是當代電商在承受非常大的并發(fā)流量的時候的一個基本手段。那么Redis在這其中是如何發(fā)揮作用的呢？我們來詳細分析一下這個限流機制：在Redis里是有一個計數(shù)器的這么一個功能的。那么我們在運用過程中，會使用其中一個key來做限流。我們會首先對key做一個初始化的賦值，假設(shè)賦值1000。那么，當上層的業(yè)務(wù)調(diào)用API的時候，Redis的限流器就會做一個decrement的操作，即進行減1的一個操作。每次調(diào)用我們都會減1，直至key的值變?yōu)?，調(diào)用會暫停。等待一定的周期之后，系統(tǒng)會重新初始化key，而實現(xiàn)電商在固定周期內(nèi)限制調(diào)用次數(shù)的功能。

聽著很美好是不是？但是在這個過程中，卻會有一些“意外”發(fā)生，其中主從不一致是核心問題。

電商節(jié)當天的流量壓力之大，不需要我們贅述。流量壓力過大會引發(fā)的問題就是，”主”Redis的buffer會產(chǎn)生一定的堆積，如果再加上”主”Redis遇上宕機，就會導(dǎo)致”主”從發(fā)生切換。鑒于Redis的”主”從是異步的，一旦主從發(fā)生切換，那么之前在“主”上面做的decrement的操作將無法同步到“從”，最后導(dǎo)致“從”上的流控的數(shù)值比真實數(shù)值少了很多。但是切換過程，對于上層的調(diào)用接口來說，是沒有感知的，它將繼續(xù)嘗試調(diào)用，即使實際已經(jīng)decrement至0，限流器依然會通過它的請求，最后這些數(shù)據(jù)都會沉淀到最底層、最薄弱的MySQL數(shù)據(jù)庫，最后導(dǎo)致整個系統(tǒng)的“雪崩”。

這時候，就是我們GaussDB ( for Redis )“強一致”功能出場的時候了。針對主從不一致的問題，GaussDB ( for Redis )在設(shè)計之初就是一個強一致的數(shù)據(jù)庫，摒棄了開源社區(qū)的異步賦值機制。它被設(shè)計成在存儲層（DFV層）去進行強一致的數(shù)據(jù)同步，而非在計算層。這樣一來，在一開始便避免了任何中間態(tài)下的數(shù)據(jù)的不一致。媽媽再也不用擔心我們宕機導(dǎo)致數(shù)據(jù)丟失啦~

硬實力二：秒擴容

我們以在疫情期間非常火熱的在線教育為例。假設(shè)一個在線教育公司使用Redis作為存儲介質(zhì)。Key對應(yīng)課程ID， Field對應(yīng)用戶ID。公司在設(shè)計之初可能沒有考慮到疫情會給他們帶來爆發(fā)式的用戶增長，導(dǎo)致哈希膨脹，最后突破Redis所在節(jié)點的內(nèi)存限制。那么針對疫情，他們必須要進行擴容。

可是擴容并不是一個簡單的事情，甚至可以說是一個高危的操作。因為Redis的擴容，是阻塞式的，以key by key的方式去進行遷移，效率非常低下。擴容期間，key是不可訪問的，并且會持續(xù)到擴容結(jié)束。

阻塞時間長是它的第一個問題。第二個問題更加嚴重。大家都知道，Redis不僅有主從，還有HA（哨兵）。一旦阻塞時間過長，你的主節(jié)點長期沒有響應(yīng)，HA就會判定你的主節(jié)點已經(jīng)掛掉，然后把主節(jié)點“殺掉”，切換主從關(guān)系，讓“從”接收請求。注意，這里的切換是發(fā)生在擴容遷移期間的，而一旦發(fā)生切換，就會導(dǎo)致擴容遷移失敗，即擴容失敗，最后導(dǎo)致哈希的數(shù)據(jù)一部分分布在源節(jié)點，另一部分分布在目標節(jié)點。這種現(xiàn)象即使是人工介入也很難修正。

我們來看看GaussDB ( for Redis )是怎么解決這個問題的。GaussDB ( for Redis ) 在設(shè)計的時候，借助了存算分離這樣一個架構(gòu)，把CPU和IO資源進行分池，從而實現(xiàn)按需擴容。 這樣的話，在遷移的時候，就不需要把數(shù)據(jù)從一個節(jié)點拷貝到另一個節(jié)點，那么擴容過程就會變得更加輕量且安全。

計算存儲分離的架構(gòu)，是一個share everything的架構(gòu)。架構(gòu)底部共享存儲，而基于共享存儲，底層的Sever，可以“看”到整個集群的數(shù)據(jù)全集。當然，這里的看到整個數(shù)據(jù)全集，只是“看”而非能夠“處理”，它只能通過Slot的路由器映射去決定它能夠處理的那一部分。換句話說，當我們在做數(shù)據(jù)擴容和遷移的時候，只需要將前面所說的路由信息從源節(jié)點遷移到目標節(jié)點即可。輕量、安全、平滑，實現(xiàn)秒擴容。

硬實力三：超可用

在數(shù)據(jù)庫領(lǐng)域，最可怕的事情，莫過于宕機。因為一旦宕機，那么鑒于數(shù)據(jù)在核心系統(tǒng)里，會導(dǎo)致整個業(yè)務(wù)系統(tǒng)都不可用，從而影響整個業(yè)務(wù)。因此，數(shù)據(jù)庫必須解決可用性問題。

華為云數(shù)據(jù)庫推出的可用性解決方案，實際上是比高可用更高，我們稱之為“超可用”。它能夠容忍N-1個節(jié)點掛掉，只要有一個節(jié)點活著，那么就能保障整個集群的可用性。

我們?nèi)匀灰郧懊娴脑诰€教育為例。在線教育的公司會把課程和課程下的用戶進行關(guān)聯(lián)，這其中就組成了一個非常大的哈希結(jié)構(gòu)。我們假設(shè)，在非常極端的情況下，此哈希所在分片的Master節(jié)點和Slave節(jié)點同時宕機，這肯定會影響用戶的課程觀看。在這種情況下，普通的Redis的集群的其他分片雖然看起來還是可用的，但是落到宕機的這個分片的所有請求，都不可用，因為它已經(jīng)徹底掛掉了且是share nothing的架構(gòu)，而其他節(jié)點也不會看到掛掉節(jié)點的數(shù)據(jù)。那么再來看華為云的GaussDB（for Redis）是怎么處理的。

鑒于它有共享存儲的能力，也即share everything，它能過把分片上的路由信息，遷移到剩下的分片，并通過share everything能力看到掛掉分片的那部分數(shù)據(jù)，現(xiàn)在只需要一把“鑰匙”，即可處理這部分數(shù)據(jù)。而這把“鑰匙”就是其中一個Slot的路由信息：Slot的路由信息把宕機分片的信息遷移到“活著”的分片Sever上，最后“活著”的Sever就擁有打開整個集群的“鑰匙”。這，就是超可用的設(shè)計。

硬實力四：低成本

技術(shù)再怎么硬，如果經(jīng)濟成本降本下來，基本是白費。假設(shè)我們有一個獨角獸公司，它對Redis的依賴非常重：歷史訂單、地圖定位、行程軌跡、用戶特征、用戶標簽等等，都存儲在Redis里。那么這里的數(shù)據(jù)量一定是非常大的，甚至可以達到100TB。那么這么大的一個規(guī)模，它里面的成本包括人工運維成本、機房建設(shè)、電力供應(yīng)等等，將會達到千萬級/年的數(shù)量級，這是非常驚人且非常難落地的。因此，降低成本成了必然的選擇。

降低成本的第一步，是要看看成本都花在了什么上面。深入分析過后可以發(fā)現(xiàn)，其實這里面有一個“二八原則”。即80%的數(shù)據(jù)是冷數(shù)據(jù)， 80%的業(yè)務(wù)對時延性要求沒有那么高。基于這樣的分析，就會發(fā)現(xiàn)我們只要利用好“二八原則”，節(jié)省成本并不是什么難事。

華為云GaussDB（for Redis）利用以下幾個方式，用有限的預(yù)算給用戶提供了無限的可能性：

冷熱分離，自動交換

無備節(jié)點，資源省半

進程無fork，內(nèi)存無半折

異步壓/解，兼顧邏輯核物理算法

與GaussDB（for Redis）相惜

為什么選擇華為云GaussDB （for Redis）呢？除了上述我們要記住的四個特性（強一致、秒擴容、超可用、低成本）之外，我們還可以從別的地方來看出它的獨特性。具體可見下圖。

協(xié)議兼容問題、性能問題、數(shù)據(jù)備份問題、數(shù)據(jù)容量問題……這些都是數(shù)據(jù)庫在使用過程中必然會遇見的問題。就好比選擇結(jié)婚對象，你需要去對比不同的方面，最后選出最好的、最合適的。

作為核心數(shù)據(jù)的存儲工具，選對就是商業(yè)成功的一半。當Redis遇見計算存儲分離，華為云GaussDB（for Redis）為此而生。

本文整理自華為云社區(qū)內(nèi)容共創(chuàng)活動第二期之【線上直播】當Redis遇見計算存儲分離。

查看活動詳情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html

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

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

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