1. 程式人生 > >Redis數據庫雲端最佳技術實踐

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

沒有 設計 比較 打通 初級 在哪裏 cloud 好處 流行

歡迎大家前往騰訊雲+社區,獲取更多騰訊海量技術實踐幹貨哦~

本文由騰訊雲數據庫 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數據庫雲端最佳技術實踐