如何分析Redis的架構(gòu)設(shè)計(jì)?
時間:2021-11-11 14:29:12
手機(jī)看文章
掃描二維碼
隨時隨地手機(jī)看文章
[導(dǎo)讀]這是一個紛雜而無規(guī)則的世界,越想忘掉的事情,越難忘記。??????正文??Redis本身內(nèi)容繁雜,要是上來就研究一細(xì)節(jié)點(diǎn),如連接池、數(shù)據(jù)結(jié)構(gòu),雖可直接學(xué)到某個點(diǎn)的詳盡源碼內(nèi)容,甚至盡快解決一些事故,但容易溺死在細(xì)節(jié)汪洋,無法整體把控Redis。最好是先建立起“架構(gòu)”。想精通Red...
Redis本身內(nèi)容繁雜,要是上來就研究一細(xì)節(jié)點(diǎn),如連接池、數(shù)據(jù)結(jié)構(gòu),雖可直接學(xué)到某個點(diǎn)的詳盡源碼內(nèi)容,甚至盡快解決一些事故,但容易溺死在細(xì)節(jié)汪洋,無法整體把控Redis。最好是先建立起“架構(gòu)”。想精通Redis,須能領(lǐng)略其總體架構(gòu),再深入具體技術(shù)點(diǎn)。構(gòu)造Redis 這種 KV DB,首要考慮:
- 數(shù)據(jù)模型
能存什么數(shù)據(jù)?如用戶信息(用戶ID、name、age、sex等),通常用 MySQL,在一個用戶ID對應(yīng)一個用戶信息集合的場景下,就是KV?DB的數(shù)據(jù)模型之一,也能滿足這類存儲需求。 - 操作接口
可以怎么操作數(shù)據(jù)?如計(jì)算多個用戶的avg年齡,KV DB則無法勝任。因其只提供了簡單的操作接口,并不支持復(fù)雜聚合計(jì)算。
數(shù)據(jù)模型
KV DB,最基本數(shù)據(jù)模型就是KV模型。選型KV DB時,一大因素就是其支持的V類型:- Memcached僅支持String V類型
- 而Redis支持的V類型還包括hash、list、set等
對 crud boy來說,不同V類型就意味著能支持多種業(yè)務(wù)的數(shù)據(jù)需求。
- PUT:新寫入或更新一個KV對
- GET:根據(jù)一個key讀取相應(yīng)的V值
- DELETE:根據(jù)一個key刪除整個KV對
- SCAN操作:根據(jù)一段K范圍,返回相應(yīng)V值
內(nèi)存 or 外存?
- 在內(nèi)存,讀寫快,百ns級。風(fēng)險(xiǎn)是一旦掉電,會丟失所有數(shù)據(jù)
- 在外存,雖可避免數(shù)據(jù)丟失,但受限于磁盤慢速讀寫(幾ms級別),KV DB整體性能會被拉低。
如緩存場景下的數(shù)據(jù)需要能快速訪問但允許丟失,則采用內(nèi)存保存KV數(shù)據(jù)。
訪問模式選型
- 通過函數(shù)庫調(diào)用供外部使用如libsimplekv.so,就是以動態(tài)鏈接庫的形式鏈接到我們自己的程序,提供KV存儲功能,如RocksDB。
- 通過網(wǎng)絡(luò)框架,以Socket通信對外提供KV對操作,可提供廣泛的KV存儲服務(wù)
如Memcached和Redis。
- 擴(kuò)大了KV DB的生態(tài)
- 給KV DB的性能、運(yùn)行模型提供了不同選型,帶來潛在問題
比如,當(dāng)客戶端發(fā)送如下命令,該命令會被封裝在網(wǎng)絡(luò)包中發(fā)送給KV DB:
PUT java edge
KV DB網(wǎng)絡(luò)框架接收到網(wǎng)絡(luò)包,并按照相應(yīng)的協(xié)議進(jìn)行解析后,可知客戶端想寫入一個鍵值對,并開始實(shí)際寫入。
I/O模型設(shè)計(jì)
網(wǎng)絡(luò)連接的處理、解析客戶端的請求及數(shù)據(jù)存取的處理,應(yīng)該選擇怎樣的線程模型?
- 一個線程,既要處理網(wǎng)絡(luò)連接、解析請求,又要完成數(shù)據(jù)存取,一旦某一步操作發(fā)生阻塞,整個線程就會阻塞住,這就降低了系統(tǒng)響應(yīng)速度
- 多線程處理不同操作,則某個線程被阻塞時,其他線程還能正常運(yùn)行。但不同線程間如果需要訪問共享資源,又會產(chǎn)生線程競爭,影響系統(tǒng)效率
所以,這里也還需精心設(shè)計(jì)。
KV對的定位
知道了要進(jìn)行的KV對操作,就得查找所要操作的KV對是否存在,這就依賴KV DB的索引模塊:讓KV DB據(jù)key找到相應(yīng)V的存儲位置。不同KV DB采用的索引:
- Memcached、Redis采用哈希表
- RocksDB采用跳表
一般內(nèi)存KV DB(如Redis)采用哈希表作為索引,主要因其KV基本都保存在內(nèi)存,而內(nèi)存高性能隨機(jī)訪問特性與哈希表O(1)復(fù)雜度匹配。
Redis的V支持多種類型,當(dāng)通過索引找到一個K所對應(yīng)V,仍需從V的復(fù)雜結(jié)構(gòu)(如set或list)中進(jìn)一步找到想要數(shù)據(jù),該操作的效率本身就依賴其實(shí)現(xiàn)結(jié)構(gòu)。而Redis便采用一些高效的索引結(jié)構(gòu)作為某些V類型的底層數(shù)據(jù)結(jié)構(gòu)。
各操作的具體邏輯
不同操作找到V的存儲位置后的操作:- GET/SCAN
根據(jù)V的存儲位置返回V值 - PUT
為該KV對分配內(nèi)存空間 - DELETE
刪除KV對,并釋放內(nèi)存空間,該過程由分配器完成
重啟后快速提供服務(wù)
KV DB的KV對大小不一,分配器在處理隨機(jī)的大小內(nèi)存塊分配時,表現(xiàn)不好的話,一旦KV對數(shù)據(jù)規(guī)模過大,可能導(dǎo)致嚴(yán)重內(nèi)存碎片。所以分配器是KV DB中的關(guān)鍵。對內(nèi)存存儲為主的Redis更重要。Redis的內(nèi)存分配器提供了多種選擇,分配效率也不同。KV DB雖依賴內(nèi)存保存數(shù)據(jù),提供快速訪問,但也希望KV DB重啟后能快速重新提供服務(wù),所以,在其存儲模塊增加持久化功能。因?yàn)榇疟P管理比內(nèi)存管理復(fù)雜,KV DB直接采用文件形式,將KV數(shù)據(jù)通過調(diào)用本地文件系統(tǒng)的操作接口保存在磁盤。
此時,KV DB只需考慮何時將內(nèi)存中的KV數(shù)據(jù)保存到文件:
- 每個KV對都落盤保存,這雖然讓數(shù)據(jù)更可靠,但每次都寫盤,性能受大影響
- 周期性把內(nèi)存中的KV對保存到文件,避免頻繁寫盤。但數(shù)據(jù)有丟失風(fēng)險(xiǎn)
所以,Redis提供了持久化功能,還有多種執(zhí)行機(jī)制和性能優(yōu)化點(diǎn)。
KV DB - Redis 架構(gòu)