摘要：協定相容問題、性能問題、資料備份問題、資料容量問題……這些都是資料庫在使用過程中必然會遇見的問題。就好比選擇結婚對象，你需要去對比不同的方面，最後選出最好的、最合适的。
近期全國兩會正在轟轟烈烈的召開，各人大代表也基于自己的一些實踐提出了自己的意見，例如“出台手機裝置适老标準”、“老師獎勵不與升學率挂鈎”、“提高留學生招生标準”等等。這些問題必不可少地引來了網上使用者的各種讨論聲音，你甚至可以想象出網上使用者深夜在努力敲鍵盤的樣子……
當然，我們今天來不是來講全國兩會的。我們技術人，技術魂，要講的是這“網上讨論的聲音”背後的技術——Redis。現如今我們網上聊天已經是家常便飯了，那麼你有沒有意識到，在我們聊天的背後，其實是有一個非常複雜的聊天系統的呢？在這複雜的聊天系統中的消息推送功能，更是其非常重要的一個子產品。一般來說，消息推送，是采用Redis的曆史資料結構來實作的。這個功能的簡單運用，就是使用者可以通過曆史的順序查找，實作檢視曆史消息的功能。
與Redis相遇
相信到這裡，大家對Redis的功能強大已經有一定認知了。那麼我們來正式介紹一下Redis：Redis（Remote Dictionary Server )，即遠端字典服務，是一個開源的使用ANSI C語言編寫、支援網絡、可基于記憶體亦可持久化的日志型、Key-Value資料庫，并提供多種語言的API。Redis本身有三個優點：快、穩、準，也就是時延低、性能好、資料結構豐富。如此強大的Redis，是“電商秒殺”等業務場景中的“熟客”：将秒殺商品的庫存數量存入Redis，通過Redis來提供一個全局庫存的實時扣減和查詢服務。
但是，沒有任何技術是完美無瑕的，Redis亦如此。Redis本身有幾個缺點：
- Redis的bgsave影響性能；
- Redis的叢集管理的一緻性非常弱；
- Redis的記憶體限制了它的存儲容量
- Redis的記憶體使用率隻有一半；
- Redis沒有冷熱分離機制。
以上都是Redis的一些缺點，是不是看完覺得Redis又被“拉下神壇”，不如不用了？不要放棄，針對開源Redis的這些缺點，華為雲資料庫團隊，做了“億點”努力！
與GaussDB（for Redis）相識
經過千難萬險，千辛萬苦，千錘百煉，華為雲自研出了一款全新的Redis資料庫，也即是GaussDB ( for Redis )！！！
華為雲的自研Redis源自于GaussDB，采用了最先進的計算存儲分離架構和多模架構——屬于業界首創。而GaussDB，則是華為雲資料庫的亮點品牌，是華為雲引以為傲的資料庫架構。
針對華為雲的GaussDB，我們來做一個簡單的介紹吧（架構圖如下）：其是基于DFV架構來建構的。而DFV則是華為内部自研的超級DataLake（分布式存儲池），可用于建構全棧資料服務架構，比如存儲部分支援FusionStorage、雲盤ECS、對象存儲OBS，資料庫部分支援的NoSQL、OLTP，大資料部分則支援HDFS的生态、Hadoop、Hbase、Hive等等。
通過下圖可以看到，在上層的資料服務和下層的存儲之間，是通過RDMA的高性能網絡來連接配接，進而能夠起到一個降低延遲時間的作用。作為最底下的存儲層，被分成了不同的存儲媒體，如SCM、NVMe SSD、HDD、衆核/多核等等。不同的存儲媒體是用來滿足不同的服務對于性能的不同的需求的。
這裡可以看出，其實GaussDB NoSQL就是一套成熟的DFV架構，也是集華為整個公司的力量去建構的一個架構最後孵化出的一個産品。其背後的心血、可用性，以及價值，都是難以估量的。
OK，我們再來看看NoSQL的“全家福”（見下圖）。可以看到，下圖已經囊括了NoSQL的全棧的資料庫，包括Redis、Influx、Cassandra、Mongo在内，都是基于GaussDB相同的架構去實作的。
拆解來看，這整套架構分為三個層次，從上往下分别是：
- 服務層（Service Layer），主要負責資料庫的協定的解析、處理、執行以及回包等等；
- 索引層（Index Layer），主要負責中間的路由及中繼資料管理等等；
- 持續化存儲層（Persistent Layer），也即是DFV POOL。
當然，我們今天不會把每個部分都進行講解，而是要對其中的Redis進行更深入的講解，其所擁有的強一緻、秒擴容、超可用、低成本這四個特點，讓它成為了“家族中最靓的仔”。我們來一步步深入了解一下它吧。
與GaussDB （for Redis）相知
在對Redis的四個特性進行深一步講解之前，我們先對GaussDB ( for Redis )有一個全面的認識吧。從架構設計上（見下圖）：
- 設計了中心化的咨詢管理--ConfigureSever（cfgsvr）：也就說用它來避免的就是社群Redis在叢集管理上弱一緻的一些問題；
- 設計了proxy的接入方式：讓一些非class的使用者通過這個proxy接入；
- 設計了Slot的資料管理：在最底層的ShardServer，設計Slot的資料管理。是說每一個項目Server會分别負責不同的Slot，每個Slot又對應不同的資料，最終的資料實際上都是落在最底層的分布式共享存儲池（DFV POOL）上。
到這裡，相信大家對GaussDB ( for Redis )的架構和性能已經有了一定的印象，那麼我們便來詳細介紹它的硬實力吧！
硬實力一：強一緻
一提到“強一緻”，很多業務開發人員會潛意識認為是一個比較高（fu）級（za）的技術，但是對他/她自身的業務邏輯，甚至他/她自身代碼能力的提高，其實沒有任何幫助。他們會說，“我不需要強一緻啊”，或者，“強一緻跟我沒有關系”。
但我們聽聽業界大牛對此的看法：強一緻不僅僅是一個技術需求，實際上它也是一個業務需求。我們如何去了解這句話呢？我們來舉個栗子：三八婦女節剛剛過去，在這個無論大大小小的節日，都要被蹭一波流量的時代，當然少不了電商們的促銷活動。電商們在做促銷活動的時候，整個平台的流量是非常大的，但是整個系統能夠抗住的壓力又非常有限，這個沖突要怎麼解決呢？這裡依賴的就是Redis的計數器，來建構的一個非常精巧的限流機制。
硬體不夠，軟體來湊。這是當代電商在承受非常大的并發流量的時候的一個基本手段。那麼Redis在這其中是如何發揮作用的呢？我們來詳細分析一下這個限流機制：在Redis裡是有一個計數器的這麼一個功能的。那麼我們在運用過程中，會使用其中一個key來做限流。我們會首先對key做一個初始化的指派，假設指派1000。那麼，當上層的業務調用API的時候，Redis的限流器就會做一個decrement的操作，即進行減1的一個操作。每次調用我們都會減1，直至key的值變為0，調用會暫停。等待一定的周期之後，系統會重新初始化key，而實作電商在固定周期内限制調用次數的功能。
聽着很美好是不是？但是在這個過程中，卻會有一些“意外”發生，其中主從不一緻是核心問題。
電商節當天的流量壓力之大，不需要我們贅述。流量壓力過大會引發的問題就是，”主”Redis的buffer會産生一定的堆積，如果再加上”主”Redis遇上當機，就會導緻”主”從發生切換。鑒于Redis的”主”從是異步的，一旦主從發生切換，那麼之前在“主”上面做的decrement的操作将無法同步到“從”，最後導緻“從”上的流控的數值比真實數值少了很多。但是切換過程，對于上層的調用接口來說，是沒有感覺的，它将繼續嘗試調用，即使實際已經decrement至0，限流器依然會通過它的請求，最後這些資料都會沉澱到最底層、最薄弱的MySQL資料庫，最後導緻整個系統的“雪崩”。
這時候，就是我們GaussDB ( for Redis )“強一緻”功能出場的時候了。針對主從不一緻的問題，GaussDB ( for Redis )在設計之初就是一個強一緻的資料庫，摒棄了開源社群的異步指派機制。它被設計成在存儲層（DFV層）去進行強一緻的資料同步，而非在計算層。這樣一來，在一開始便避免了任何中間态下的資料的不一緻。媽媽再也不用擔心我們當機導緻資料丢失啦~
硬實力二：秒擴容
我們以在疫情期間非常火熱的線上教育為例。假設一個線上教育公司使用Redis作為存儲媒體。Key對應課程ID， Field對應使用者ID。公司在設計之初可能沒有考慮到疫情會給他們帶來爆發式的使用者增長，導緻哈希膨脹，最後突破Redis所在節點的記憶體限制。那麼針對疫情，他們必須要進行擴容。
可是擴容并不是一個簡單的事情，甚至可以說是一個高危的操作。因為Redis的擴容，是阻塞式的，以key by key的方式去進行遷移，效率非常低下。擴容期間，key是不可通路的，并且會持續到擴容結束。
阻塞時間長是它的第一個問題。第二個問題更加嚴重。大家都知道，Redis不僅有主從，還有HA（哨兵）。一旦阻塞時間過長，你的主節點長期沒有響應，HA就會判定你的主節點已經挂掉，然後把主節點“殺掉”，切換主從關系，讓“從”接收請求。注意，這裡的切換是發生在擴容遷移期間的，而一旦發生切換，就會導緻擴容遷移失敗，即擴容失敗，最後導緻哈希的資料一部分分布在源節點，另一部分分布在目标節點。這種現象即使是人工介入也很難修正。
我們來看看GaussDB ( for Redis )是怎麼解決這個問題的。GaussDB ( for Redis ) 在設計的時候，借助了存算分離這樣一個架構，把CPU和IO資源進行分池，進而實作按需擴容。 這樣的話，在遷移的時候，就不需要把資料從一個節點拷貝到另一個節點，那麼擴容過程就會變得更加輕量且安全。
計算存儲分離的架構，是一個share everything的架構。架構底部共享存儲，而基于共享存儲，底層的Sever，可以“看”到整個叢集的資料全集。當然，這裡的看到整個資料全集，隻是“看”而非能夠“處理”，它隻能通過Slot的路由器映射去決定它能夠處理的那一部分。換句話說，當我們在做資料擴容和遷移的時候，隻需要将前面所說的路由資訊從源節點遷移到目标節點即可。輕量、安全、平滑，實作秒擴容。
硬實力三：超可用
在資料庫領域，最可怕的事情，莫過于當機。因為一旦當機，那麼鑒于資料在核心系統裡，會導緻整個業務系統都不可用，進而影響整個業務。是以，資料庫必須解決可用性問題。
華為雲資料庫推出的可用性解決方案，實際上是比高可用更高，我們稱之為“超可用”。它能夠容忍N-1個節點挂掉，隻要有一個節點活着，那麼就能保障整個叢集的可用性。
我們仍然以前面的線上教育為例。線上教育的公司會把課程和課程下的使用者進行關聯，這其中就組成了一個非常大的哈希結構。我們假設，在非常極端的情況下，此哈希所在分片的Master節點和Slave節點同時當機，這肯定會影響使用者的課程觀看。在這種情況下，普通的Redis的叢集的其他分片雖然看起來還是可用的，但是落到當機的這個分片的所有請求，都不可用，因為它已經徹底挂掉了且是share nothing的架構，而其他節點也不會看到挂掉節點的資料。那麼再來看華為雲的GaussDB（for Redis）是怎麼處理的。
鑒于它有共享存儲的能力，也即share everything，它能過把分片上的路由資訊，遷移到剩下的分片，并通過share everything能力看到挂掉分片的那部分資料，現在隻需要一把“鑰匙”，即可處理這部分資料。而這把“鑰匙”就是其中一個Slot的路由資訊：Slot的路由資訊把當機分片的資訊遷移到“活着”的分片Sever上，最後“活着”的Sever就擁有打開整個叢集的“鑰匙”。這，就是超可用的設計。
硬實力四：低成本
技術再怎麼硬，如果經濟成本降本下來，基本是白費。假設我們有一個獨角獸公司，它對Redis的依賴非常重：曆史訂單、地圖定位、行程軌迹、使用者特征、使用者标簽等等，都存儲在Redis裡。那麼這裡的資料量一定是非常大的，甚至可以達到100TB。那麼這麼大的一個規模，它裡面的成本包括人工運維成本、機房建設、電力供應等等，将會達到千萬級/年的數量級，這是非常驚人且非常難落地的。是以，降低成本成了必然的選擇。
降低成本的第一步，是要看看成本都花在了什麼上面。深入分析過後可以發現，其實這裡面有一個“二八原則”。即80%的資料是冷資料， 80%的業務對時延性要求沒有那麼高。基于這樣的分析，就會發現我們隻要利用好“二八原則”，節省成本并不是什麼難事。
華為雲GaussDB（for Redis）利用以下幾個方式，用有限的預算給使用者提供了無限的可能性：
- 冷熱分離，自動交換
- 無備節點，資源省半
- 程序無fork，記憶體無半折
- 異步壓/解，兼顧邏輯核實體算法
與GaussDB（for Redis）相惜
為什麼選擇華為雲GaussDB （for Redis）呢？除了上述我們要記住的四個特性（強一緻、秒擴容、超可用、低成本）之外，我們還可以從别的地方來看出它的獨特性。具體可見下圖。
協定相容問題、性能問題、資料備份問題、資料容量問題……這些都是資料庫在使用過程中必然會遇見的問題。就好比選擇結婚對象，你需要去對比不同的方面，最後選出最好的、最合适的。
作為核心資料的存儲工具，選對就是商業成功的一半。當Redis遇見計算存儲分離，華為雲GaussDB（for Redis）為此而生。
本文分享自華為雲社群《【雲駐共創】Redis與計算存儲分離四部曲：相識相惜，相輔相成》，原文作者：啟明。
檢視活動詳情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html
點選關注，第一時間了解華為雲新鮮技術~