溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

發(fā)布時(shí)間:2022-01-15 17:03:18 來(lái)源:億速云 閱讀:129 作者:iii 欄目:數(shù)據(jù)庫(kù)

這篇文章主要介紹了Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些的相關(guān)知識(shí),內(nèi)容詳細(xì)易懂,操作簡(jiǎn)單快捷,具有一定借鑒價(jià)值,相信大家閱讀完這篇Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些文章都會(huì)有所收獲,下面我們一起來(lái)看看吧。

前言

Redis是目前最火爆的內(nèi)存數(shù)據(jù)庫(kù)之一,通過(guò)在內(nèi)存中讀寫(xiě)數(shù)據(jù),大大提高了讀寫(xiě)速度,可以說(shuō)Redis是實(shí)現(xiàn)網(wǎng)站高并發(fā)不可或缺的一部分。我們使用Redis時(shí),會(huì)接觸Redis的5種對(duì)象類型(字符串、哈希、列表、集合、有序集合),豐富的類型是Redis相對(duì)于Memcached等的一大優(yōu)勢(shì)。在了解Redis的5種對(duì)象類型的用法和特點(diǎn)的基礎(chǔ)上,進(jìn)一步了解Redis的內(nèi)存模型,對(duì)Redis的使用有很大幫助,例如:

  • 1、估算Redis內(nèi)存使用量。目前為止,內(nèi)存的使用成本仍然相對(duì)較高,使用內(nèi)存不能無(wú)所顧忌;根據(jù)需求合理的評(píng)估Redis的內(nèi)存使用量,選擇合適的機(jī)器配置,可以在滿足需求的情況下節(jié)約成本。

  • 2、優(yōu)化內(nèi)存占用。了解Redis內(nèi)存模型可以選擇更合適的數(shù)據(jù)類型和編碼,更好的利用Redis內(nèi)存。

  • 3、分析解決問(wèn)題。當(dāng)Redis出現(xiàn)阻塞、內(nèi)存占用等問(wèn)題時(shí),盡快發(fā)現(xiàn)導(dǎo)致問(wèn)題的原因,便于分析解決問(wèn)題。

這篇文章主要介紹Redis的內(nèi)存模型(以3.0為例),包括Redis占用內(nèi)存的情況及如何查詢、不同的對(duì)象類型在內(nèi)存中的編碼方式、內(nèi)存分配器(jemalloc)、簡(jiǎn)單動(dòng)態(tài)字符串(SDS)、RedisObject等;然后在此基礎(chǔ)上介紹幾個(gè)Redis內(nèi)存模型的應(yīng)用。

一、Redis內(nèi)存統(tǒng)計(jì)

工欲善其事必先利其器,在說(shuō)明Redis內(nèi)存之前首先說(shuō)明如何統(tǒng)計(jì)Redis使用內(nèi)存的情況。

在客戶端通過(guò)redis-cli連接服務(wù)器后(后面如無(wú)特殊說(shuō)明,客戶端一律使用redis-cli),通過(guò)info命令可以查看內(nèi)存使用情況:

info memory

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

其中,info命令可以顯示redis服務(wù)器的許多信息,包括服務(wù)器基本信息、CPU、內(nèi)存、持久化、客戶端連接信息等等;memory是參數(shù),表示只顯示內(nèi)存相關(guān)的信息。

返回結(jié)果中比較重要的幾個(gè)說(shuō)明如下:

(1)used_memory:Redis分配器分配的內(nèi)存總量(單位是字節(jié)),包括使用的虛擬內(nèi)存(即swap);Redis分配器后面會(huì)介紹。used_memory_human只是顯示更友好。

(2)used_memory_rss:Redis進(jìn)程占據(jù)操作系統(tǒng)的內(nèi)存(單位是字節(jié)),與top及ps命令看到的值是一致的;除了分配器分配的內(nèi)存之外,used_memory_rss還包括進(jìn)程運(yùn)行本身需要的內(nèi)存、內(nèi)存碎片等,但是不包括虛擬內(nèi)存。

因此,used_memory和used_memory_rss,前者是從Redis角度得到的量,后者是從操作系統(tǒng)角度得到的量。二者之所以有所不同,一方面是因?yàn)閮?nèi)存碎片和Redis進(jìn)程運(yùn)行需要占用內(nèi)存,使得前者可能比后者小,另一方面虛擬內(nèi)存的存在,使得前者可能比后者大。

由于在實(shí)際應(yīng)用中,Redis的數(shù)據(jù)量會(huì)比較大,此時(shí)進(jìn)程運(yùn)行占用的內(nèi)存與Redis數(shù)據(jù)量和內(nèi)存碎片相比,都會(huì)小得多;因此used_memory_rss和used_memory的比例,便成了衡量Redis內(nèi)存碎片率的參數(shù);這個(gè)參數(shù)就是mem_fragmentation_ratio。

(3)mem_fragmentation_ratio:內(nèi)存碎片比率,該值是used_memory_rss / used_memory的比值。

mem_fragmentation_ratio一般大于1,且該值越大,內(nèi)存碎片比例越大。mem_fragmentation_ratio<1,說(shuō)明Redis使用了虛擬內(nèi)存,由于虛擬內(nèi)存的媒介是磁盤(pán),比內(nèi)存速度要慢很多,當(dāng)這種情況出現(xiàn)時(shí),應(yīng)該及時(shí)排查,如果內(nèi)存不足應(yīng)該及時(shí)處理,如增加Redis節(jié)點(diǎn)、增加Redis服務(wù)器的內(nèi)存、優(yōu)化應(yīng)用等。

一般來(lái)說(shuō),mem_fragmentation_ratio在1.03左右是比較健康的狀態(tài)(對(duì)于jemalloc來(lái)說(shuō));上面截圖中的mem_fragmentation_ratio值很大,是因?yàn)檫€沒(méi)有向Redis中存入數(shù)據(jù),Redis進(jìn)程本身運(yùn)行的內(nèi)存使得used_memory_rss   比used_memory大得多。

(4)mem_allocator:Redis使用的內(nèi)存分配器,在編譯時(shí)指定;可以是 libc  、jemalloc或者tcmalloc,默認(rèn)是jemalloc;截圖中使用的便是默認(rèn)的jemalloc。

二、Redis內(nèi)存劃分

Redis作為內(nèi)存數(shù)據(jù)庫(kù),在內(nèi)存中存儲(chǔ)的內(nèi)容主要是數(shù)據(jù)(鍵值對(duì));通過(guò)前面的敘述可以知道,除了數(shù)據(jù)以外,Redis的其他部分也會(huì)占用內(nèi)存。

Redis的內(nèi)存占用主要可以劃分為以下幾個(gè)部分:

1、數(shù)據(jù)

作為數(shù)據(jù)庫(kù),數(shù)據(jù)是最主要的部分;這部分占用的內(nèi)存會(huì)統(tǒng)計(jì)在used_memory中。

Redis使用鍵值對(duì)存儲(chǔ)數(shù)據(jù),其中的值(對(duì)象)包括5種類型,即字符串、哈希、列表、集合、有序集合。這5種類型是Redis對(duì)外提供的,實(shí)際上,在Redis內(nèi)部,每種類型可能有2種或更多的內(nèi)部編碼實(shí)現(xiàn);此外,Redis在存儲(chǔ)對(duì)象時(shí),并不是直接將數(shù)據(jù)扔進(jìn)內(nèi)存,而是會(huì)對(duì)對(duì)象進(jìn)行各種包裝:如redisObject、SDS等;這篇文章后面將重點(diǎn)介紹Redis中數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)。

2、進(jìn)程本身運(yùn)行需要的內(nèi)存

Redis主進(jìn)程本身運(yùn)行肯定需要占用內(nèi)存,如代碼、常量池等等;這部分內(nèi)存大約幾兆,在大多數(shù)生產(chǎn)環(huán)境中與Redis數(shù)據(jù)占用的內(nèi)存相比可以忽略。這部分內(nèi)存不是由jemalloc分配,因此不會(huì)統(tǒng)計(jì)在used_memory中。

補(bǔ)充說(shuō)明:除了主進(jìn)程外,Redis創(chuàng)建的子進(jìn)程運(yùn)行也會(huì)占用內(nèi)存,如Redis執(zhí)行AOF、RDB重寫(xiě)時(shí)創(chuàng)建的子進(jìn)程。當(dāng)然,這部分內(nèi)存不屬于Redis進(jìn)程,也不會(huì)統(tǒng)計(jì)在used_memory和used_memory_rss中。

3、緩沖內(nèi)存

緩沖內(nèi)存包括:

  • 客戶端緩沖區(qū)、復(fù)制積壓緩沖區(qū)、AOF緩沖區(qū)等;

  • 其中,客戶端緩沖存儲(chǔ)客戶端連接的輸入輸出緩沖;

  • 復(fù)制積壓緩沖用于部分復(fù)制功能;

  • AOF緩沖區(qū)用于在進(jìn)行AOF重寫(xiě)時(shí),保存最近的寫(xiě)入命令。

在了解相應(yīng)功能之前,不需要知道這些緩沖的細(xì)節(jié);這部分內(nèi)存由jemalloc分配,因此會(huì)統(tǒng)計(jì)在used_memory中。

4、內(nèi)存碎片

內(nèi)存碎片是Redis在分配、回收物理內(nèi)存過(guò)程中產(chǎn)生的。例如,如果對(duì)數(shù)據(jù)的更改頻繁,而且數(shù)據(jù)之間的大小相差很大,可能導(dǎo)致redis釋放的空間在物理內(nèi)存中并沒(méi)有釋放,但redis又無(wú)法有效利用,這就形成了內(nèi)存碎片。內(nèi)存碎片不會(huì)統(tǒng)計(jì)在used_memory中。

內(nèi)存碎片的產(chǎn)生與對(duì)數(shù)據(jù)進(jìn)行的操作、數(shù)據(jù)的特點(diǎn)等都有關(guān);此外,與使用的內(nèi)存分配器也有關(guān)系:如果內(nèi)存分配器設(shè)計(jì)合理,可以盡可能的減少內(nèi)存碎片的產(chǎn)生。后面將要說(shuō)到的jemalloc便在控制內(nèi)存碎片方面做的很好。

如果Redis服務(wù)器中的內(nèi)存碎片已經(jīng)很大,可以通過(guò)安全重啟的方式減小內(nèi)存碎片:因?yàn)橹貑⒅?,Redis重新從備份文件中讀取數(shù)據(jù),在內(nèi)存中進(jìn)行重排,為每個(gè)數(shù)據(jù)重新選擇合適的內(nèi)存單元,減小內(nèi)存碎片。

三、Redis數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)

1、概述

關(guān)于Redis數(shù)據(jù)存儲(chǔ)的細(xì)節(jié),涉及到內(nèi)存分配器(如jemalloc)、簡(jiǎn)單動(dòng)態(tài)字符串(SDS)、5種對(duì)象類型及內(nèi)部編碼、redisObject。在講述具體內(nèi)容之前,先說(shuō)明一下這幾個(gè)概念之間的關(guān)系。

下圖是執(zhí)行set hello world時(shí),所涉及到的數(shù)據(jù)模型。

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

圖片來(lái)源:https://searchdatabase.techtarget.com.cn/7-20218/

(1)dictEntry:Redis是Key-Value數(shù)據(jù)庫(kù),因此對(duì)每個(gè)鍵值對(duì)都會(huì)有一個(gè)dictEntry,里面存儲(chǔ)了指向Key和Value的指針;next指向下一個(gè)dictEntry,與本Key-Value無(wú)關(guān)。

(2)Key:圖中右上角可見(jiàn),Key(”hello”)并不是直接以字符串存儲(chǔ),而是存儲(chǔ)在SDS結(jié)構(gòu)中。

(3)redisObject:Value(“world”)既不是直接以字符串存儲(chǔ),也不是像Key一樣直接存儲(chǔ)在SDS中,而是存儲(chǔ)在redisObject中。實(shí)際上,不論Value是5種類型的哪一種,都是通過(guò)redisObject來(lái)存儲(chǔ)的;而redisObject中的type字段指明了Value對(duì)象的類型,ptr字段則指向?qū)ο笏诘牡刂?。不過(guò)可以看出,字符串對(duì)象雖然經(jīng)過(guò)了redisObject的包裝,但仍然需要通過(guò)SDS存儲(chǔ)。

實(shí)際上,redisObject除了type和ptr字段以外,還有其他字段圖中沒(méi)有給出,如用于指定對(duì)象內(nèi)部編碼的字段;后面會(huì)詳細(xì)介紹。

(4)jemalloc:無(wú)論是DictEntry對(duì)象,還是redisObject、SDS對(duì)象,都需要內(nèi)存分配器(如jemalloc)分配內(nèi)存進(jìn)行存儲(chǔ)。以DictEntry對(duì)象為例,有3個(gè)指針組成,在64位機(jī)器下占24個(gè)字節(jié),jemalloc會(huì)為它分配32字節(jié)大小的內(nèi)存單元。

下面來(lái)分別介紹jemalloc、redisObject、SDS、對(duì)象類型及內(nèi)部編碼。

2、jemalloc

Redis在編譯時(shí)便會(huì)指定內(nèi)存分配器;內(nèi)存分配器可以是 libc 、jemalloc或者tcmalloc,默認(rèn)是jemalloc。

jemalloc作為Redis的默認(rèn)內(nèi)存分配器,在減小內(nèi)存碎片方面做的相對(duì)比較好。jemalloc在64位系統(tǒng)中,將內(nèi)存空間劃分為小、大、巨大三個(gè)范圍;每個(gè)范圍內(nèi)又劃分了許多小的內(nèi)存塊單位;當(dāng)Redis存儲(chǔ)數(shù)據(jù)時(shí),會(huì)選擇大小最合適的內(nèi)存塊進(jìn)行存儲(chǔ)。

jemalloc劃分的內(nèi)存單元如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

圖片來(lái)源:http://blog.csdn.net/zhengpeitao/article/details/76573053

例如,如果需要存儲(chǔ)大小為130字節(jié)的對(duì)象,jemalloc會(huì)將其放入160字節(jié)的內(nèi)存單元中。

3、redisObject

前面說(shuō)到,Redis對(duì)象有5種類型;無(wú)論是哪種類型,Redis都不會(huì)直接存儲(chǔ),而是通過(guò)redisObject對(duì)象進(jìn)行存儲(chǔ)。

redisObject對(duì)象非常重要,Redis對(duì)象的類型、內(nèi)部編碼、內(nèi)存回收、共享對(duì)象等功能,都需要redisObject支持,下面將通過(guò)redisObject的結(jié)構(gòu)來(lái)說(shuō)明它是如何起作用的。

redisObject的定義如下(不同版本的Redis可能稍稍有所不同):

typedef struct redisObject { unsigned type:4; unsigned encoding:4; unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */ int refcount; void *ptr; } robj;

redisObject的每個(gè)字段的含義和作用如下:

(1)type

type字段表示對(duì)象的類型,占4個(gè)比特;目前包括REDIS_STRING(字符串)、REDIS_LIST  (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。

當(dāng)我們執(zhí)行type命令時(shí),便是通過(guò)讀取RedisObject的type字段獲得對(duì)象的類型;如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

(2)encoding

encoding表示對(duì)象的內(nèi)部編碼,占4個(gè)比特。

對(duì)于Redis支持的每種類型,都有至少兩種內(nèi)部編碼,例如對(duì)于字符串,有int、embstr、raw三種編碼。通過(guò)encoding屬性,Redis可以根據(jù)不同的使用場(chǎng)景來(lái)為對(duì)象設(shè)置不同的編碼,大大提高了Redis的靈活性和效率。以列表對(duì)象為例,有壓縮列表和雙端鏈表兩種編碼方式;如果列表中的元素較少,Redis傾向于使用壓縮列表進(jìn)行存儲(chǔ),因?yàn)閴嚎s列表占用內(nèi)存更少,而且比雙端鏈表可以更快載入;當(dāng)列表對(duì)象元素較多時(shí),壓縮列表就會(huì)轉(zhuǎn)化為更適合存儲(chǔ)大量元素的雙端鏈表。

通過(guò)object encoding命令,可以查看對(duì)象采用的編碼方式,如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

5種對(duì)象類型對(duì)應(yīng)的編碼方式以及使用條件,將在后面介紹。

(3)lru

lru記錄的是對(duì)象***一次被命令程序訪問(wèn)的時(shí)間,占據(jù)的比特?cái)?shù)不同的版本有所不同(如4.0版本占24比特,2.6版本占22比特)。

通過(guò)對(duì)比lru時(shí)間與當(dāng)前時(shí)間,可以計(jì)算某個(gè)對(duì)象的空轉(zhuǎn)時(shí)間;object idletime命令可以顯示該空轉(zhuǎn)時(shí)間(單位是秒)。object  idletime命令的一個(gè)特殊之處在于它不改變對(duì)象的lru值。

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

lru值除了通過(guò)object  idletime命令打印之外,還與Redis的內(nèi)存回收有關(guān)系:如果Redis打開(kāi)了maxmemory選項(xiàng),且內(nèi)存回收算法選擇的是volatile-lru或allkeys&mdash;lru,那么當(dāng)Redis內(nèi)存占用超過(guò)maxmemory指定的值時(shí),Redis會(huì)優(yōu)先選擇空轉(zhuǎn)時(shí)間最長(zhǎng)的對(duì)象進(jìn)行釋放。

(4)refcount

refcount與共享對(duì)象

refcount記錄的是該對(duì)象被引用的次數(shù),類型為整型。refcount的作用,主要在于對(duì)象的引用計(jì)數(shù)和內(nèi)存回收。

  • 當(dāng)創(chuàng)建新對(duì)象時(shí),refcount初始化為1;

  • 當(dāng)有新程序使用該對(duì)象時(shí),refcount加1;

  • 當(dāng)對(duì)象不再被一個(gè)新程序使用時(shí),refcount減1;

  • 當(dāng)refcount變?yōu)?時(shí),對(duì)象占用的內(nèi)存會(huì)被釋放。

Redis中被多次使用的對(duì)象(refcount>1),稱為共享對(duì)象。Redis為了節(jié)省內(nèi)存,當(dāng)有一些對(duì)象重復(fù)出現(xiàn)時(shí),新的程序不會(huì)創(chuàng)建新的對(duì)象,而是仍然使用原來(lái)的對(duì)象。這個(gè)被重復(fù)使用的對(duì)象,就是共享對(duì)象。目前共享對(duì)象僅支持整數(shù)值的字符串對(duì)象。

共享對(duì)象的具體實(shí)現(xiàn)

Redis的共享對(duì)象目前只支持整數(shù)值的字符串對(duì)象。之所以如此,實(shí)際上是對(duì)內(nèi)存和CPU(時(shí)間)的平衡:共享對(duì)象雖然會(huì)降低內(nèi)存消耗,但是判斷兩個(gè)對(duì)象是否相等卻需要消耗額外的時(shí)間。

  • 對(duì)于整數(shù)值,判斷操作復(fù)雜度為O(1);

  • 對(duì)于普通字符串,判斷復(fù)雜度為O(n);

  • 而對(duì)于哈希、列表、集合和有序集合,判斷的復(fù)雜度為O(n^2)。

雖然共享對(duì)象只能是整數(shù)值的字符串對(duì)象,但是5種類型都可能使用共享對(duì)象(如哈希、列表等的元素可以使用)。

就目前的實(shí)現(xiàn)來(lái)說(shuō),Redis服務(wù)器在初始化時(shí),會(huì)創(chuàng)建10000個(gè)字符串對(duì)象,值分別是0~9999的整數(shù)值;當(dāng)Redis需要使用值為0~9999的字符串對(duì)象時(shí),可以直接使用這些共享對(duì)象。10000這個(gè)數(shù)字可以通過(guò)調(diào)整參數(shù)REDIS_SHARED_INTEGERS(4.0中是OBJ_SHARED_INTEGERS)的值進(jìn)行改變。

共享對(duì)象的引用次數(shù)可以通過(guò)object refcount命令查看,如下圖所示。命令執(zhí)行的結(jié)果頁(yè)佐證了只有0~9999之間的整數(shù)會(huì)作為共享對(duì)象。

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

(5)ptr

ptr指針指向具體的數(shù)據(jù),如前面的例子中,set hello world,ptr指向包含字符串world的SDS。

(6)總結(jié)

綜上所述,redisObject的結(jié)構(gòu)與對(duì)象類型、編碼、內(nèi)存回收、共享對(duì)象都有關(guān)系;一個(gè)redisObject對(duì)象的大小為16字節(jié):

  • 4bit+4bit+24bit+4Byte+8Byte=16Byte。

4、SDS

Redis沒(méi)有直接使用C字符串(即以空字符&rsquo;\0&rsquo;結(jié)尾的字符數(shù)組)作為默認(rèn)的字符串表示,而是使用了SDS。SDS是簡(jiǎn)單動(dòng)態(tài)字符串(Simple  Dynamic String)的縮寫(xiě)。

(1)SDS結(jié)構(gòu)

sds的結(jié)構(gòu)如下:

struct sdshdr {     int len;     int free;     char buf[]; };

其中,buf表示字節(jié)數(shù)組,用來(lái)存儲(chǔ)字符串;len表示buf已使用的長(zhǎng)度,free表示buf未使用的長(zhǎng)度。下面是兩個(gè)例子。

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些
圖片來(lái)源:《Redis設(shè)計(jì)與實(shí)現(xiàn)》

通過(guò)SDS的結(jié)構(gòu)可以看出,buf數(shù)組的長(zhǎng)度=free+len+1(其中1表示字符串結(jié)尾的空字符);所以,一個(gè)SDS結(jié)構(gòu)占據(jù)的空間為:free所占長(zhǎng)度+len所占長(zhǎng)度+  buf數(shù)組的長(zhǎng)度=4+4+free+len+1=free+len+9。

(2)SDS與C字符串的比較

SDS在C字符串的基礎(chǔ)上加入了free和len字段,帶來(lái)了很多好處:

  1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

  2. 獲取字符串長(zhǎng)度:SDS是O(1),C字符串是O(n)

  3. 緩沖區(qū)溢出:使用C字符串的API時(shí),如果字符串長(zhǎng)度增加(如strcat操作)而忘記重新分配內(nèi)存,很容易造成緩沖區(qū)的溢出;而SDS由于記錄了長(zhǎng)度,相應(yīng)的API在可能造成緩沖區(qū)溢出時(shí)會(huì)自動(dòng)重新分配內(nèi)存,杜絕了緩沖區(qū)溢出。

  4. 修改字符串時(shí)內(nèi)存的重分配:對(duì)于C字符串,如果要修改字符串,必須要重新分配內(nèi)存(先釋放再申請(qǐng)),因?yàn)槿绻麤](méi)有重新分配,字符串長(zhǎng)度增大時(shí)會(huì)造成內(nèi)存緩沖區(qū)溢出,字符串長(zhǎng)度減小時(shí)會(huì)造成內(nèi)存泄露。而對(duì)于SDS,由于可以記錄len和free,因此解除了字符串長(zhǎng)度和空間數(shù)組長(zhǎng)度之間的關(guān)聯(lián),可以在此基礎(chǔ)上進(jìn)行優(yōu)化:空間預(yù)分配策略(即分配內(nèi)存時(shí)比實(shí)際需要的多)使得字符串長(zhǎng)度增大時(shí)重新分配內(nèi)存的概率大大減小;惰性空間釋放策略使得字符串長(zhǎng)度減小時(shí)重新分配內(nèi)存的概率大大減小。

  5. 存取二進(jìn)制數(shù)據(jù):SDS可以,C字符串不可以。因?yàn)镃字符串以空字符作為字符串結(jié)束的標(biāo)識(shí),而對(duì)于一些二進(jìn)制文件(如圖片等),內(nèi)容可能包括空字符串,因此C字符串無(wú)法正確存取;而SDS以字符串長(zhǎng)度len來(lái)作為字符串結(jié)束標(biāo)識(shí),因此沒(méi)有這個(gè)問(wèn)題。

此外,由于SDS中的buf仍然使用了C字符串(即以&rsquo;\0&rsquo;結(jié)尾),因此SDS可以使用C字符串庫(kù)中的部分函數(shù);但是需要注意的是,只有當(dāng)SDS用來(lái)存儲(chǔ)文本數(shù)據(jù)時(shí)才可以這樣使用,在存儲(chǔ)二進(jìn)制數(shù)據(jù)時(shí)則不行(&rsquo;\0&rsquo;不一定是結(jié)尾)。

(3)SDS與C字符串的應(yīng)用

Redis在存儲(chǔ)對(duì)象時(shí),一律使用SDS代替C字符串。例如set hello world命令,hello和world都是以SDS的形式存儲(chǔ)的。而sadd  myset member1 member2 member3命令,不論是鍵(”myset”),還是集合中的元素(”member1”、  ”member2”和”member3”),都是以SDS的形式存儲(chǔ)。除了存儲(chǔ)對(duì)象,SDS還用于存儲(chǔ)各種緩沖區(qū)。

只有在字符串不會(huì)改變的情況下,如打印日志時(shí),才會(huì)使用C字符串。

四、Redis的對(duì)象類型與內(nèi)部編碼

前面已經(jīng)說(shuō)過(guò),Redis支持5種對(duì)象類型,而每種結(jié)構(gòu)都有至少兩種編碼;這樣做的好處在于:一方面接口與實(shí)現(xiàn)分離,當(dāng)需要增加或改變內(nèi)部編碼時(shí),用戶使用不受影響,另一方面可以根據(jù)不同的應(yīng)用場(chǎng)景切換內(nèi)部編碼,提高效率。

Redis各種對(duì)象類型支持的內(nèi)部編碼如下圖所示(圖中版本是Redis3.0,Redis后面版本中又增加了內(nèi)部編碼,略過(guò)不提;本章所介紹的內(nèi)部編碼都是基于3.0的):

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些
圖片來(lái)源:《Redis設(shè)計(jì)與實(shí)現(xiàn)》

關(guān)于Redis內(nèi)部編碼的轉(zhuǎn)換,都符合以下規(guī)律:編碼轉(zhuǎn)換在Redis寫(xiě)入數(shù)據(jù)時(shí)完成,且轉(zhuǎn)換過(guò)程不可逆,只能從小內(nèi)存編碼向大內(nèi)存編碼轉(zhuǎn)換。

1、字符串

(1)概況

字符串是最基礎(chǔ)的類型,因?yàn)樗械逆I都是字符串類型,且字符串之外的其他幾種復(fù)雜類型的元素也是字符串。

字符串長(zhǎng)度不能超過(guò)512MB。

(2)內(nèi)部編碼

字符串類型的內(nèi)部編碼有3種,它們的應(yīng)用場(chǎng)景如下:

  • int:8個(gè)字節(jié)的長(zhǎng)整型。字符串值是整型時(shí),這個(gè)值使用long整型表示。

  • embstr:<=39字節(jié)的字符串。embstr與raw都使用redisObject和sds保存數(shù)據(jù),區(qū)別在于,embstr的使用只分配一次內(nèi)存空間(因此redisObject和sds是連續(xù)的),而raw需要分配兩次內(nèi)存空間(分別為redisObject和sds分配空間)。因此與raw相比,embstr的好處在于創(chuàng)建時(shí)少分配一次空間,刪除時(shí)少釋放一次空間,以及對(duì)象的所有數(shù)據(jù)連在一起,尋找方便。而embstr的壞處也很明顯,如果字符串的長(zhǎng)度增加需要重新分配內(nèi)存時(shí),整個(gè)redisObject和sds都需要重新分配空間,因此redis中的embstr實(shí)現(xiàn)為只讀。

  • raw:大于39個(gè)字節(jié)的字符串

示例如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

embstr和raw進(jìn)行區(qū)分的長(zhǎng)度,是39;是因?yàn)閞edisObject的長(zhǎng)度是16字節(jié),sds的長(zhǎng)度是9+字符串長(zhǎng)度;因此當(dāng)字符串長(zhǎng)度是39時(shí),embstr的長(zhǎng)度正好是16+9+39=64,jemalloc正好可以分配64字節(jié)的內(nèi)存單元。

(3)編碼轉(zhuǎn)換

當(dāng)int數(shù)據(jù)不再是整數(shù),或大小超過(guò)了long的范圍時(shí),自動(dòng)轉(zhuǎn)化為raw。

而對(duì)于embstr,由于其實(shí)現(xiàn)是只讀的,因此在對(duì)embstr對(duì)象進(jìn)行修改時(shí),都會(huì)先轉(zhuǎn)化為raw再進(jìn)行修改,因此,只要是修改embstr對(duì)象,修改后的對(duì)象一定是raw的,無(wú)論是否達(dá)到了39個(gè)字節(jié)。示例如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

2、列表

(1)概況

列表(list)用來(lái)存儲(chǔ)多個(gè)有序的字符串,每個(gè)字符串稱為元素;一個(gè)列表可以存儲(chǔ)2^32-1個(gè)元素。Redis中的列表支持兩端插入和彈出,并可以獲得指定位置(或范圍)的元素,可以充當(dāng)數(shù)組、隊(duì)列、棧等。

(2)內(nèi)部編碼

列表的內(nèi)部編碼可以是壓縮列表(ziplist)或雙端鏈表(linkedlist)。

雙端鏈表:由一個(gè)list結(jié)構(gòu)和多個(gè)listNode結(jié)構(gòu)組成;典型結(jié)構(gòu)如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些
圖片來(lái)源:《Redis設(shè)計(jì)與實(shí)現(xiàn)》

通過(guò)圖中可以看出,雙端鏈表同時(shí)保存了表頭指針和表尾指針,并且每個(gè)節(jié)點(diǎn)都有指向前和指向后的指針;鏈表中保存了列表的長(zhǎng)度;dup、free和match為節(jié)點(diǎn)值設(shè)置類型特定函數(shù),所以鏈表可以用于保存各種不同類型的值。而鏈表中每個(gè)節(jié)點(diǎn)指向的是type為字符串的redisObject。

壓縮列表:壓縮列表是Redis為了節(jié)約內(nèi)存而開(kāi)發(fā)的,是由一系列特殊編碼的連續(xù)內(nèi)存塊(而不是像雙端鏈表一樣每個(gè)節(jié)點(diǎn)是指針)組成的順序型數(shù)據(jù)結(jié)構(gòu);具體結(jié)構(gòu)相對(duì)比較復(fù)雜,略。與雙端鏈表相比,壓縮列表可以節(jié)省內(nèi)存空間,但是進(jìn)行修改或增刪操作時(shí),復(fù)雜度較高;因此當(dāng)節(jié)點(diǎn)數(shù)量較少時(shí),可以使用壓縮列表;但是節(jié)點(diǎn)數(shù)量多時(shí),還是使用雙端鏈表劃算。

壓縮列表不僅用于實(shí)現(xiàn)列表,也用于實(shí)現(xiàn)哈希、有序列表;使用非常廣泛。

(3)編碼轉(zhuǎn)換

只有同時(shí)滿足下面兩個(gè)條件時(shí),才會(huì)使用壓縮列表:

  • 列表中元素?cái)?shù)量小于512個(gè);

  • 列表中所有字符串對(duì)象都不足64字節(jié)。

如果有一個(gè)條件不滿足,則使用雙端列表;且編碼只可能由壓縮列表轉(zhuǎn)化為雙端鏈表,反方向則不可能。

下圖展示了列表編碼轉(zhuǎn)換的特點(diǎn):

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

其中,單個(gè)字符串不能超過(guò)64字節(jié),是為了便于統(tǒng)一分配每個(gè)節(jié)點(diǎn)的長(zhǎng)度;這里的64字節(jié)是指字符串的長(zhǎng)度,不包括SDS結(jié)構(gòu),因?yàn)閴嚎s列表使用連續(xù)、定長(zhǎng)內(nèi)存塊存儲(chǔ)字符串,不需要SDS結(jié)構(gòu)指明長(zhǎng)度。后面提到壓縮列表,也會(huì)強(qiáng)調(diào)長(zhǎng)度不超過(guò)64字節(jié),原理與這里類似。

3、哈希

(1)概況

哈希(作為一種數(shù)據(jù)結(jié)構(gòu)),不僅是redis對(duì)外提供的5種對(duì)象類型的一種(與字符串、列表、集合、有序結(jié)合并列),也是Redis作為Key-Value數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)結(jié)構(gòu)。為了說(shuō)明的方便,在本文后面當(dāng)使用“內(nèi)層的哈?!睍r(shí),代表的是redis對(duì)外提供的5種對(duì)象類型的一種;使用“外層的哈?!贝窻edis作為Key-Value數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)結(jié)構(gòu)。

(2)內(nèi)部編碼

內(nèi)層的哈希使用的內(nèi)部編碼可以是壓縮列表(ziplist)和哈希表(hashtable)兩種;Redis的外層的哈希則只使用了hashtable。

壓縮列表前面已介紹。與哈希表相比,壓縮列表用于元素個(gè)數(shù)少、元素長(zhǎng)度小的場(chǎng)景;其優(yōu)勢(shì)在于集中存儲(chǔ),節(jié)省空間;同時(shí),雖然對(duì)于元素的操作復(fù)雜度也由O(n)變?yōu)榱薕(1),但由于哈希中元素?cái)?shù)量較少,因此操作的時(shí)間并沒(méi)有明顯劣勢(shì)。

hashtable:一個(gè)hashtable由1個(gè)dict結(jié)構(gòu)、2個(gè)dictht結(jié)構(gòu)、1個(gè)dictEntry指針數(shù)組(稱為bucket)和多個(gè)dictEntry結(jié)構(gòu)組成。

正常情況下(即hashtable沒(méi)有進(jìn)行rehash時(shí))各部分關(guān)系如下圖所示:

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

圖片改編自:《Redis設(shè)計(jì)與實(shí)現(xiàn)》

下面從底層向上依次介紹各個(gè)部分:

dictEntry

dictEntry結(jié)構(gòu)用于保存鍵值對(duì),結(jié)構(gòu)定義如下:

typedef struct dictEntry{     void *key;     union{         void *val;         uint64_tu64;         int64_ts64;     }v;     struct dictEntry *next; }dictEntry;

其中,各個(gè)屬性的功能如下:

  • key:鍵值對(duì)中的鍵;

  • val:鍵值對(duì)中的值,使用union(即共用體)實(shí)現(xiàn),存儲(chǔ)的內(nèi)容既可能是一個(gè)指向值的指針,也可能是64位整型,或無(wú)符號(hào)64位整型;

  • next:指向下一個(gè)dictEntry,用于解決哈希沖突問(wèn)題

在64位系統(tǒng)中,一個(gè)dictEntry對(duì)象占24字節(jié)(key/val/next各占8字節(jié))。

bucket

bucket是一個(gè)數(shù)組,數(shù)組的每個(gè)元素都是指向dictEntry結(jié)構(gòu)的指針。redis中bucket數(shù)組的大小計(jì)算規(guī)則如下:大于dictEntry的、最小的2^n;例如,如果有1000個(gè)dictEntry,那么bucket大小為1024;如果有1500個(gè)dictEntry,則bucket大小為2048。

dictht

dictht結(jié)構(gòu)如下:

typedef struct dictht{     dictEntry **table;     unsigned long size;     unsigned long sizemask;     unsigned long used; }dictht;

其中,各個(gè)屬性的功能說(shuō)明如下:

  • table屬性是一個(gè)指針,指向bucket;

  • size屬性記錄了哈希表的大小,即bucket的大小;

  • used記錄了已使用的dictEntry的數(shù)量;

  • sizemask屬性的值總是為size-1,這個(gè)屬性和哈希值一起決定一個(gè)鍵在table中存儲(chǔ)的位置。

dict

一般來(lái)說(shuō),通過(guò)使用dictht和dictEntry結(jié)構(gòu),便可以實(shí)現(xiàn)普通哈希表的功能;但是Redis的實(shí)現(xiàn)中,在dictht結(jié)構(gòu)的上層,還有一個(gè)dict結(jié)構(gòu)。下面說(shuō)明dict結(jié)構(gòu)的定義及作用。

dict結(jié)構(gòu)如下:

typedef struct dict{     dictType *type;     void *privdata;     dictht ht[2];     int trehashidx; } dict;

其中,type屬性和privdata屬性是為了適應(yīng)不同類型的鍵值對(duì),用于創(chuàng)建多態(tài)字典。

ht屬性和trehashidx屬性則用于rehash,即當(dāng)哈希表需要擴(kuò)展或收縮時(shí)使用。ht是一個(gè)包含兩個(gè)項(xiàng)的數(shù)組,每項(xiàng)都指向一個(gè)dictht結(jié)構(gòu),這也是Redis的哈希會(huì)有1個(gè)dict、2個(gè)dictht結(jié)構(gòu)的原因。通常情況下,所有的數(shù)據(jù)都是存在放dict的ht[0]中,ht[1]只在rehash的時(shí)候使用。dict進(jìn)行rehash操作的時(shí)候,將ht[0]中的所有數(shù)據(jù)rehash到ht[1]中。然后將ht[1]賦值給ht[0],并清空ht[1]。

因此,Redis中的哈希之所以在dictht和dictEntry結(jié)構(gòu)之外還有一個(gè)dict結(jié)構(gòu),一方面是為了適應(yīng)不同類型的鍵值對(duì),另一方面是為了rehash。

(3)編碼轉(zhuǎn)換

如前所述,Redis中內(nèi)層的哈希既可能使用哈希表,也可能使用壓縮列表。

只有同時(shí)滿足下面兩個(gè)條件時(shí),才會(huì)使用壓縮列表:

  • 哈希中元素?cái)?shù)量小于512個(gè);

  • 哈希中所有鍵值對(duì)的鍵和值字符串長(zhǎng)度都小于64字節(jié)。

如果有一個(gè)條件不滿足,則使用哈希表;且編碼只可能由壓縮列表轉(zhuǎn)化為哈希表,反方向則不可能。

下圖展示了Redis內(nèi)層的哈希編碼轉(zhuǎn)換的特點(diǎn):

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

4、集合

(1)概況

集合(set)與列表類似,都是用來(lái)保存多個(gè)字符串,但集合與列表有兩點(diǎn)不同:集合中的元素是無(wú)序的,因此不能通過(guò)索引來(lái)操作元素;集合中的元素不能有重復(fù)。

一個(gè)集合中最多可以存儲(chǔ)2^32-1個(gè)元素;除了支持常規(guī)的增刪改查,Redis還支持多個(gè)集合取交集、并集、差集。

(2)內(nèi)部編碼

集合的內(nèi)部編碼可以是整數(shù)集合(intset)或哈希表(hashtable)。

哈希表前面已經(jīng)講過(guò),這里略過(guò)不提;需要注意的是,集合在使用哈希表時(shí),值全部被置為null。

整數(shù)集合的結(jié)構(gòu)定義如下:

typedef struct intset{     uint32_t encoding;     uint32_t length;     int8_t contents[]; } intset;

其中,encoding代表contents中存儲(chǔ)內(nèi)容的類型,雖然contents(存儲(chǔ)集合中的元素)是int8_t類型,但實(shí)際上其存儲(chǔ)的值是int16_t、int32_t或int64_t,具體的類型便是由encoding決定的;length表示元素個(gè)數(shù)。

整數(shù)集合適用于集合所有元素都是整數(shù)且集合元素?cái)?shù)量較小的時(shí)候,與哈希表相比,整數(shù)集合的優(yōu)勢(shì)在于集中存儲(chǔ),節(jié)省空間;同時(shí),雖然對(duì)于元素的操作復(fù)雜度也由O(n)變?yōu)榱薕(1),但由于集合數(shù)量較少,因此操作的時(shí)間并沒(méi)有明顯劣勢(shì)。

(3)編碼轉(zhuǎn)換

只有同時(shí)滿足下面兩個(gè)條件時(shí),集合才會(huì)使用整數(shù)集合:

  • 集合中元素?cái)?shù)量小于512個(gè);

  • 集合中所有元素都是整數(shù)值。

如果有一個(gè)條件不滿足,則使用哈希表;且編碼只可能由整數(shù)集合轉(zhuǎn)化為哈希表,反方向則不可能。

下圖展示了集合編碼轉(zhuǎn)換的特點(diǎn):

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

5、有序集合

(1)概況

有序集合與集合一樣,元素都不能重復(fù);但與集合不同的是,有序集合中的元素是有順序的。與列表使用索引下標(biāo)作為排序依據(jù)不同,有序集合為每個(gè)元素設(shè)置一個(gè)分?jǐn)?shù)(score)作為排序依據(jù)。

(2)內(nèi)部編碼

有序集合的內(nèi)部編碼可以是壓縮列表(ziplist)或跳躍表(skiplist)。ziplist在列表和哈希中都有使用,前面已經(jīng)講過(guò),這里略過(guò)不提。

跳躍表是一種有序數(shù)據(jù)結(jié)構(gòu),通過(guò)在每個(gè)節(jié)點(diǎn)中維持多個(gè)指向其他節(jié)點(diǎn)的指針,從而達(dá)到快速訪問(wèn)節(jié)點(diǎn)的目的。除了跳躍表,實(shí)現(xiàn)有序數(shù)據(jù)結(jié)構(gòu)的另一種典型實(shí)現(xiàn)是平衡樹(shù);大多數(shù)情況下,跳躍表的效率可以和平衡樹(shù)媲美,且跳躍表實(shí)現(xiàn)比平衡樹(shù)簡(jiǎn)單很多,因此redis中選用跳躍表代替平衡樹(shù)。

跳躍表支持平均O(logN)、最壞O(N)的復(fù)雜點(diǎn)進(jìn)行節(jié)點(diǎn)查找,并支持順序操作。Redis的跳躍表實(shí)現(xiàn)由zskiplist和zskiplistNode兩個(gè)結(jié)構(gòu)組成:前者用于保存跳躍表信息(如頭結(jié)點(diǎn)、尾節(jié)點(diǎn)、長(zhǎng)度等),后者用于表示跳躍表節(jié)點(diǎn)。具體結(jié)構(gòu)相對(duì)比較復(fù)雜,略。

(3)編碼轉(zhuǎn)換

只有同時(shí)滿足下面兩個(gè)條件時(shí),才會(huì)使用壓縮列表:

  • 有序集合中元素?cái)?shù)量小于128個(gè);

  • 有序集合中所有成員長(zhǎng)度都不足64字節(jié)。

如果有一個(gè)條件不滿足,則使用跳躍表;且編碼只可能由壓縮列表轉(zhuǎn)化為跳躍表,反方向則不可能。

下圖展示了有序集合編碼轉(zhuǎn)換的特點(diǎn):

Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些

五、應(yīng)用舉例

了解Redis的內(nèi)存模型之后,下面通過(guò)幾個(gè)例子說(shuō)明其應(yīng)用。

1、估算Redis內(nèi)存使用量

要估算redis中的數(shù)據(jù)占據(jù)的內(nèi)存大小,需要對(duì)redis的內(nèi)存模型有比較全面的了解,包括前面介紹的hashtable、sds、redisobject、各種對(duì)象類型的編碼方式等。

下面以最簡(jiǎn)單的字符串類型來(lái)進(jìn)行說(shuō)明。

假設(shè)有90000個(gè)鍵值對(duì),每個(gè)key的長(zhǎng)度是7個(gè)字節(jié),每個(gè)value的長(zhǎng)度也是7個(gè)字節(jié)(且key和value都不是整數(shù));下面來(lái)估算這90000個(gè)鍵值對(duì)所占用的空間。在估算占據(jù)空間之前,首先可以判定字符串類型使用的編碼方式:embstr。

90000個(gè)鍵值對(duì)占據(jù)的內(nèi)存空間主要可以分為兩部分:一部分是90000個(gè)dictEntry占據(jù)的空間;一部分是鍵值對(duì)所需要的bucket空間。

每個(gè)dictEntry占據(jù)的空間包括:

  • 1) 一個(gè)dictEntry,24字節(jié),jemalloc會(huì)分配32字節(jié)的內(nèi)存塊

  • 2) 一個(gè)key,7字節(jié),所以SDS(key)需要7+9=16個(gè)字節(jié),jemalloc會(huì)分配16字節(jié)的內(nèi)存塊

  • 3) 一個(gè)redisObject,16字節(jié),jemalloc會(huì)分配16字節(jié)的內(nèi)存塊

  • 4) 一個(gè)value,7字節(jié),所以SDS(value)需要7+9=16個(gè)字節(jié),jemalloc會(huì)分配16字節(jié)的內(nèi)存塊

  • 5) 綜上,一個(gè)dictEntry需要32+16+16+16=80個(gè)字節(jié)。

bucket空間:bucket數(shù)組的大小為大于90000的最小的2^n,是131072;每個(gè)bucket元素為8字節(jié)(因?yàn)?4位系統(tǒng)中指針大小為8字節(jié))。

因此,可以估算出這90000個(gè)鍵值對(duì)占據(jù)的內(nèi)存大小為:90000*80 + 131072*8 = 8248576。

下面寫(xiě)個(gè)程序在redis中驗(yàn)證一下:

public class RedisTest {  public static Jedis jedis = new Jedis("localhost", 6379);  public static void main(String[] args) throws Exception{ Long m1 = Long.valueOf(getMemory()); insertData(); Long m2 = Long.valueOf(getMemory()); System.out.println(m2 - m1); }  public static void insertData(){ for(int i = 10000; i < 100000; i++){ jedis.set("aa" + i, "aa" + i); //key和value長(zhǎng)度都是7字節(jié),且不是整數(shù) } }  public static String getMemory(){ String memoryAllLine = jedis.info("memory"); String usedMemoryLine = memoryAllLine.split("\r\n")[1]; String memory = usedMemoryLine.substring(usedMemoryLine.indexOf(':') + 1); return memory; } }

運(yùn)行結(jié)果:8247552

理論值與結(jié)果值誤差在萬(wàn)分之1.2,對(duì)于計(jì)算需要多少內(nèi)存來(lái)說(shuō),這個(gè)精度已經(jīng)足夠了。之所以會(huì)存在誤差,是因?yàn)樵谖覀儾迦?0000條數(shù)據(jù)之前redis已分配了一定的bucket空間,而這些bucket空間尚未使用。

作為對(duì)比將key和value的長(zhǎng)度由7字節(jié)增加到8字節(jié),則對(duì)應(yīng)的SDS變?yōu)?7個(gè)字節(jié),jemalloc會(huì)分配32個(gè)字節(jié),因此每個(gè)dictEntry占用的字節(jié)數(shù)也由80字節(jié)變?yōu)?12字節(jié)。此時(shí)估算這90000個(gè)鍵值對(duì)占據(jù)內(nèi)存大小為:90000*112  + 131072*8 = 11128576。

在redis中驗(yàn)證代碼如下(只修改插入數(shù)據(jù)的代碼):

public static void insertData(){ for(int i = 10000; i < 100000; i++){ jedis.set("aaa" + i, "aaa" + i); //key和value長(zhǎng)度都是8字節(jié),且不是整數(shù) } }

運(yùn)行結(jié)果:11128576;估算準(zhǔn)確。

對(duì)于字符串類型之外的其他類型,對(duì)內(nèi)存占用的估算方法是類似的,需要結(jié)合具體類型的編碼方式來(lái)確定。

2、優(yōu)化內(nèi)存占用

了解redis的內(nèi)存模型,對(duì)優(yōu)化redis內(nèi)存占用有很大幫助。下面介紹幾種優(yōu)化場(chǎng)景。

(1)利用jemalloc特性進(jìn)行優(yōu)化

上一小節(jié)所講述的90000個(gè)鍵值便是一個(gè)例子。由于jemalloc分配內(nèi)存時(shí)數(shù)值是不連續(xù)的,因此key/value字符串變化一個(gè)字節(jié),可能會(huì)引起占用內(nèi)存很大的變動(dòng);在設(shè)計(jì)時(shí)可以利用這一點(diǎn)。

例如,如果key的長(zhǎng)度如果是8個(gè)字節(jié),則SDS為17字節(jié),jemalloc分配32字節(jié);此時(shí)將key長(zhǎng)度縮減為7個(gè)字節(jié),則SDS為16字節(jié),jemalloc分配16字節(jié);則每個(gè)key所占用的空間都可以縮小一半。

(2)使用整型/長(zhǎng)整型

如果是整型/長(zhǎng)整型,Redis會(huì)使用int類型(8字節(jié))存儲(chǔ)來(lái)代替字符串,可以節(jié)省更多空間。因此在可以使用長(zhǎng)整型/整型代替字符串的場(chǎng)景下,盡量使用長(zhǎng)整型/整型。

(3)共享對(duì)象

利用共享對(duì)象,可以減少對(duì)象的創(chuàng)建(同時(shí)減少了redisObject的創(chuàng)建),節(jié)省內(nèi)存空間。目前redis中的共享對(duì)象只包括10000個(gè)整數(shù)(0-9999);可以通過(guò)調(diào)整REDIS_SHARED_INTEGERS參數(shù)提高共享對(duì)象的個(gè)數(shù);例如將REDIS_SHARED_INTEGERS調(diào)整到20000,則0-19999之間的對(duì)象都可以共享。

考慮這樣一種場(chǎng)景:論壇網(wǎng)站在redis中存儲(chǔ)了每個(gè)帖子的瀏覽數(shù),而這些瀏覽數(shù)絕大多數(shù)分布在0-20000之間,這時(shí)候通過(guò)適當(dāng)增大REDIS_SHARED_INTEGERS參數(shù),便可以利用共享對(duì)象節(jié)省內(nèi)存空間。

(4)避免過(guò)度設(shè)計(jì)

然而需要注意的是,不論是哪種優(yōu)化場(chǎng)景,都要考慮內(nèi)存空間與設(shè)計(jì)復(fù)雜度的權(quán)衡;而設(shè)計(jì)復(fù)雜度會(huì)影響到代碼的復(fù)雜度、可維護(hù)性。

如果數(shù)據(jù)量較小,那么為了節(jié)省內(nèi)存而使得代碼的開(kāi)發(fā)、維護(hù)變得更加困難并不劃算;還是以前面講到的90000個(gè)鍵值對(duì)為例,實(shí)際上節(jié)省的內(nèi)存空間只有幾MB。但是如果數(shù)據(jù)量有幾千萬(wàn)甚至上億,考慮內(nèi)存的優(yōu)化就比較必要了。

3、關(guān)注內(nèi)存碎片率

內(nèi)存碎片率是一個(gè)重要的參數(shù),對(duì)redis 內(nèi)存的優(yōu)化有重要意義。

如果內(nèi)存碎片率過(guò)高(jemalloc在1.03左右比較正常),說(shuō)明內(nèi)存碎片多,內(nèi)存浪費(fèi)嚴(yán)重;這時(shí)便可以考慮重啟redis服務(wù),在內(nèi)存中對(duì)數(shù)據(jù)進(jìn)行重排,減少內(nèi)存碎片。

如果內(nèi)存碎片率小于1,說(shuō)明redis內(nèi)存不足,部分?jǐn)?shù)據(jù)使用了虛擬內(nèi)存(即swap);由于虛擬內(nèi)存的存取速度比物理內(nèi)存差很多(2-3個(gè)數(shù)量級(jí)),此時(shí)redis的訪問(wèn)速度可能會(huì)變得很慢。因此必須設(shè)法增大物理內(nèi)存(可以增加服務(wù)器節(jié)點(diǎn)數(shù)量,或提高單機(jī)內(nèi)存),或減少redis中的數(shù)據(jù)。

要減少redis中的數(shù)據(jù),除了選用合適的數(shù)據(jù)類型、利用共享對(duì)象等,還有一點(diǎn)是要設(shè)置合理的數(shù)據(jù)回收策略(maxmemory-policy),當(dāng)內(nèi)存達(dá)到一定量后,根據(jù)不同的優(yōu)先級(jí)對(duì)內(nèi)存進(jìn)行回收。

關(guān)于“Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些”這篇文章的內(nèi)容就介紹到這里,感謝各位的閱讀!相信大家對(duì)“Redis內(nèi)存模型及應(yīng)用知識(shí)點(diǎn)有哪些”知識(shí)都有一定的了解,大家如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道。

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI