本文由騰訊雲數據庫 TencentDB發表於雲+社區專欄

鄒鵬，騰訊高級工程師，騰訊雲數據庫Redis負責人，多年數據庫、網絡安全研發經驗。在網絡、計算、存儲、安全等領域有深入的研究和豐富的產品化經驗。 在Redis、MySQL等數據庫的高可用、高可靠和中間件方面有豐富的實踐經驗。

這次過來主要是和大家分享一下，騰訊雲上個月正式上線的Redis4.0集群版的相關內容，跟大家分享我們在做集群版的時候有哪些思考，我們怎麽去設計整個系統架構，最終我們做了哪些東西。大概會有三個點，第一個點是說Redis的使命，我們看Redis是什麽產品，為什麽這麽火，第二塊就是騰訊雲Redis4.0集群設計經歷了哪些思考，最終做成什麽樣子，最後是2018年年初，登錄到騰訊雲的自研兼容Redis協議的CKV引擎，他是怎麽樣的一個架構設計。

我覺得每個偉人都是帶著使命來的，Redis也是一樣的，每個時代都有每個時代的明星，Redis是移動互聯網的時代數據庫明星，Memcached誕生在Mysql無法滿足業務高並發低時延需求的時代，但是Memcached在使用體驗，業務場景的支持方面太過簡單，所有就有了Redis的誕生，Redis是一個高性能、低延遲、支持復雜數據結構的瑞士×××。

我們接下來看一下這個屬於Redis數據庫的時代，今天是一個什麽樣的情況，這是這個月剛刷新的數據，Redis的排名已經超過了ES了，已經位列第七了，而且一直持續增長，越來越熱，這個背後還隱藏了一個數據，Redis的官網現在有65%的流量來自中國大陸，全球都在用，但是中國的程序員用得最6。這裏可能是跟國情有關，咋們國家人多，所以要求高並發，現在服務類最火，服務質量第一要求就是快，可以看我們現在都快遞、打車、外賣這些場景，第一體驗都是快，這是Redis的優勢。

這塊是Redis標簽的一個排名，我們可以看到第一個是Performance，性能包括高並發低時延，我們來看下Redis在並發上面能做到多少，Redis能做到單核每秒跑10萬次請求，還可以在5萬並發的時候做到99%的請求在1毫秒內返回。in-memory cache，用Redis不用建表，這對程序員來說，我覺得確實是開發者給我們的禮物，所以Redis能夠滿足這個時代的要求，能夠籠絡我們這幫開發者，能夠成為這個時代的明星。其實Redis已經有10年的發展歷史，但是我們可以看到這兩年在我們雲上還在持續快速的增長，Redis主要場景還是在於緩存，從我們現在的數據來看，如果拋開遊戲的場景不說，80%的場景都是緩存，所以它還是緩存數據庫，下面還有很多標簽，我們總結下來Redis是一個非常快非常簡單好用的內存數據庫，這就是Redis簡單的畫像。

進入到今天的正題，我來跟大家分享一下我們做了接近半年騰訊雲的Redis4.0Cluster版本的情況，我們基於社區4.0版本+自研的Proxy打造的分布式緩存數據庫，我們先認識一下官方Cluster是什麽樣的一個數據庫，相對於主從版的話，在邏輯層面上多了管理層，官方Cluster有數據層面和管理層面，我們可以看一下這兩個層面的東西，第一層面是在集群這裏有一個邏輯在裏面，負責把數據Sharding到不同分片，把數據打散，第二塊是自治管理。另外一塊就是做了平滑遷移的支持，在新增版裏面加了兩個命令，如果數據沒在這個分片上可以告訴你在別的分片上，再加上智能客戶端的配合，就算數據搬了之後，也不會訪問失敗，總有一個地方能找到它，這是數據層面的情況。另外就是下層管理平面的內容，管理平面是完全自治的管理系統，基於gossip協議，一個無中心化的方案，不需要第三方組建，無節點管理完全是靠大家商量，這個人究竟還活不活著，大家商量出來的，不需要第三方參與的。另外一塊就是高可用，會有完整的一套檢測邏輯以及投票把它判死的邏輯，集群版做了兩大塊特征，這是官方源生的情況。

我們認為Redis Cluster一定要有一個Proxy，第一原生集群版必須有一個智能客戶端支持，剛才說了在集群版裏面新增了幾個命令，你訪問的時候如果這個數據沒在這個分片，會告訴你到別的地方取，原來不需要處理這種命令，當遷移到集群版遇到這種命令就傻了，沒辦法跑了。這個時候你需要智能客戶端的支持。另外的情況是你的客戶端需要感知後端的架構，把所有信息同步到客戶端，然後客戶端做分片。對運維比較簡單，但對於我們開發者是極其不友好的，在雲上，IP資源很珍貴，我們現在有一個電商的大客戶，現在用128片集群版，用的是一組兩從，所有節點要128×3，就400多個IP，一個C網都不夠，這種用法用起來對客戶端太不友好。為什麽必須要Proxy，在某些層面上要豐富某些功能，在集群方面的監控做的不夠，比如說數據傾斜，因為是無中心化設計，沒有統管全局，我們要做流量隔離，要做熱Key監控、訪問監控，要麽改變Redis-server代碼要麽用中間件實現。做雲的時候雲上的客戶太多了，會有很多客戶，很多需求，很多功能要上，都去改Redis的代碼，Redis的代碼很難維護，最簡單的辦法就是做一個Smart Proxy，它相當於一個智能客戶端。我們把這塊Sharding的邏輯下沈到中間件。

我們看一下如果要選一個Proxy有什麽可選的？應該大家這些都很熟悉，Twemproxy是一個老古董了，代理組件最大的硬傷是無法支持擴容和縮容，你在業務增長的時候重新搬數據根本受不了。另外就是Codis，國內的大牛spinlock開發的，Codis做了一套完整的方案提供給大家，系統很大很復雜。確實沒有官方做的優雅，同時也改了Redis Server的代碼，還有一個硬傷是沒有官方血統。這是主流我們能看到的比較常見的方案，雲上我們是沒辦法直接搬的，因為無法在雲上顧到成千上萬的用戶的需求的。

看我們騰訊雲做的方案，後面是官方源生的Cluster，完全是自治的版本，我們做了少部分的優化。再往前是智能客戶端，會完成代理轉發，做大量定制化監控以及數據Sharding。再往前面就是LB，主要是為了提供VIP，這樣對開發者來說看到一個IP就行了，像單機版用它就OK了，這種是比較優雅的方案，所有的東西都屏蔽到後端，我們只需要寫和讀就可以了，這是咱們最終的方案。

Redis集群版本身數據操作層面是很簡單很穩定的，在做集群版的時候我們在兩個地方做了很大的努力，第一個是數據遷移，我們看一下哪些場景會有數據遷移的需求？

聽眾：老師，你好，我是一個初級人員，我們公司現在也在用Redis集群，如果想用你們騰訊雲的話，這個步驟能解決你剛剛說的代理，這些東西由你們管理嗎？之前都是我們自己百度搭了百度官方的集群方案在用。

鄒鵬：你們現在數據在哪裏？

聽眾：放在自己的本地，我們有意向購買騰訊雲的Redis。

鄒鵬：你們現在有數據，業務上雲之後數據要上來，我們有DTS的平臺，只要你把網絡打通，我們工具就能連到你們的Redis，數據就可以傳過來。

聽眾：謝謝老師。

鄒鵬：雲計算的優勢在於你如果想要立馬就能有，整個雲在SAAS層PASS層，國內都已經很完善了。如果大家以後創業，把這些辛苦的事交給我們就行了。

接下來回到這個話題，數據遷移，集群版談到穩定性，最大的挑戰就是數據遷移，哪些場景下會有數據遷移呢？擴容，比如說擴容的話，可以看到我們的場景，三個維度，橫向分片數，128片，垂直維度從4G到32G維度可以調整，還有副本數5個副本，10萬寫，50萬讀。這種情況下都會產生擴容和縮容的場景。咱們業已在初期的時候少買一點，之後可以橫向或者縱向擴。我們花了很大的代價做這塊，還有一塊集群版，這個東西難免產生數據傾斜，假如你的Key設計的不合理，就會出現你數據基本上都是打在某分片上，這個時候數據傾斜了就要要涉及數據遷移。

有個比較難的地方，遷移過程中比較平滑，極端情況下訪問某個Key正在遷移的時候，會等幾個周期，具體原理可以下來或者我們交流，現在的情況，比如原來搬數據的話肯定會斷連接，現在集群版的支持，加上我們中間有一個PROXY可以屏蔽掉，在你業務跑的時候不需要停服就可以進行擴容或者縮容，不過還是建議在業務的低峰期做，我們指定時間升級，比如定時到淩晨三點鐘做這個事情就妥妥的。Redis有兩大痛，第一是大Key，第二是熱Key。如果我們現在比如說遇到大Key的問題，我們數據遷移的時候是搬這個大Key還是其他的Key？

分析大Key要做RDB分析，這個過程很慢，我們在雲上每天都做備份，我們在這裏做了一個異步懶惰掃大Key的事情，在搬遷之前挨個把Key都掃一下遍，然後就結合數據的算法，哪裏有大Key就知道了，我們就避開大Key 進行搬遷。現在至少遇到大Key不會讓你的Redis卡住。

聽眾：你們搬遷的話對前面的數據有影響嗎？

鄒鵬：搬遷本身設計就考慮到業務不用感知，不用非要掛靠停服，這塊我們也是想可用性做到極致。

我們需要在Proxy做全局監控，怎麽炸幹Proxy的價值呢？1、訪問監控；2、Key分析；3、指標監控；4、慢查詢；5、告警配置；6、流量隔離。

我們會分析實例哪些Key，告訴你在Redis裏面放了什麽Key，然後前綴分別是什麽，還有就是大Key，準確的大Key是通過RDP分析做的。上面提的大Key情況是數據搬遷的時候我們要實時看一下，也是異步掃的過程。有時候想看一下開發究竟寫了什麽數據在裏面，可以通過這些數據了解到你的Key的情況，還有常見的指標監控，流量、命中率這種，很重要，緩存、可以通過命中率看到，這個時候10%5%的時候是有問題的，這個指標很關鍵，能夠幫助我們及時看到異常的問題，容量、流量、還有命中以及查詢miss的情況。

慢查詢不是特別多，但是會有。還是整個騰訊雲有完整的監控系統，所有指標都是接入雲監控的，配置一個指標，觸碰閾值就能發告警。很容易出現大Key，會影響到你其他的實例，這個時候我們必須要對流量做隔離，我們在Proxy做隔離，每個規格對應哪些流量，保證業務的可用性。

這就是最終的版圖，從服務器對應下面4.0的集群，這是三層的情況，這邊是周邊的支撐系統，比如說監控、資源管理、備份。源生有分布式自治，我們還會做更細層面的，比較主機層，最大的保證可用性。

這是跨可用和高可用的問題，現在都怕挖挖機，我們會提供跨可用和高可用的方案，比如你在廣州一區，買了一個集群4.0，我會復制到集群到別的可用區，在每個區提供不同的IP，都可以訪問和寫，只不過在同時訪問的時候，寫再返回到主可用區。異常情況發生的時候，整個可用區不可訪問，你的業務調到可用區二區還可以用，就是這麽一個架構保證在可用性方面做到地域級別的可用性。

另外介紹一下18年初登錄騰訊雲的兼容Redis協議的自研CKV引擎，CKV名字很簡單很樸素，一看就是做研發人員取的名字，不會說牽牛星織女星的名字。這塊是整體的情況， 2009年開始立項，最大的背景就是QQ空間，那個時候就起來了，2013年訪問量10億，去年年底我們就基本完成了兼容Redis協議的開發，然後上騰訊雲，之前是私有協議，所以這塊上雲，大家接受不了，去年做的重點事情是兼容Redis協議，在今年年初我們就正式上線了，大家到時候也可以在我們的官網上能看到，

為什麽這裏要單獨提一下這塊的設計，沒有Proxy集群不叫優雅的集群版，但CKV確實沒有Proxy，但是它也確實很優雅。Proxy有很多好處，但有一個問題就是費錢，成本很高。我們就用另外的方案，就是CKV最早的方案，沒有Proxy，請求會隨機打到任意一個分片，每個分片會有全局的slot信息，如果發現這個請求不能在當前分片處理能夠轉發到目的節點去處理，每個節點都可以是Proxy，好處是省錢，時間更低。這邊是邏輯的概念圖，比如說CVM到LB到數據節點，假如你的請求達到從節點，這個從節點點會把請求放到主節點，主節點把數據返回完成之後再返回從節點，這是CKV不一樣的方案，是源生分布式的。另外在網絡上突破了單線程，Redis的消耗是Key的操作還有網絡的操作，像QPS5-10萬的時候，網絡占比很大，我們把網絡收發變成多線程，既保證數據一致性，又把性能提升，最高單位節點能夠跑到30萬+，比如說你需要事務的支持，但是需要事務支持的時候很難用集群版的，這個時候可以考慮這種模式去支持，既要突破10萬QPS的，又要做到數據無分片的情況。

Q & A

Q：你好，我問一下Redis跟Mysql的占比分別是多少？

A：我很好奇，你問這個問題的背景是啥？

Q：MySQL使用的占比會比你這個大很多。

A：你可以看這張圖，實際情況大概是這樣子，大概10：1的樣子。

Q：在單節點的時候，考慮過Redis怎麽實現高分組嗎？我們是不是可以考慮通過DPDK嗎？

A：咱們也嘗試過這樣的思路，投入產出比不會特別高，現在技術圈流行一個概念就是去OS，去FS，去協議棧，但是這塊的成本說實話特別的高，，投入特別的大，TCP很慢很老很保守，但是跑了那麽多年，如果新做一套成本會特別的高，投入產出比很低，真正單個線程要寫特別大樂得場景不會特別多，在有Redis 集群版的情況下我們可以考慮通過分片的擴展來提升寫性能，通過添加副本來提高讀性能。所以這塊也是我們經歷過的一些思考。

相關閱讀
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社區發布，更多原文請點擊

搜索關註公眾號「雲加社區」，第一時間獲取技術幹貨，關註後回復1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！

Redis數據庫雲端最佳技術實踐