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

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由騰訊雲數據庫 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的價值呢？一、訪問監控；二、Key分析；三、指標監控；四、慢查詢；五、告警配置；六、流量隔離。

咱們會分析實例哪些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的，又要作到數據無分片的狀況。更多數據庫前沿技術可關注 咱們公衆號：騰訊雲數據庫CDB

Q & A

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

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

Q：MySQL使用的佔比會比你這個大不少。

A：你能夠看這張圖，實際狀況大概是這樣子，大概10：1的樣子。

Q：在單節點的時候，考慮過Redis怎麼實現高分組嗎？咱們是否是能夠考慮經過DPDK嗎？

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

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

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

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

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