Redis 是目前最火爆的內(nèi)存數(shù)據(jù)庫之一，通過在內(nèi)存中讀寫數(shù)據(jù)，大大提高了讀寫速度，可以說 Redis 是實現(xiàn)網(wǎng)站高并發(fā)不可或缺的一部分。

我們使用 Redis 時，會接觸 Redis 的 5 種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是 Redis 相對于 Memcached 等的一大優(yōu)勢。

在了解 Redis 的 5 種對象類型的用法和特點的基礎(chǔ)上，進一步了解 Redis 的內(nèi)存模型，對 Redis 的使用有很大幫助，例如：

• 估算 Redis 內(nèi)存使用量。目前為止，內(nèi)存的使用成本仍然相對較高，使用內(nèi)存不能無所顧忌；根據(jù)需求合理的評估 Redis 的內(nèi)存使用量，選擇合適的機器配置，可以在滿足需求的情況下節(jié)約成本。
• 優(yōu)化內(nèi)存占用。了解 Redis 內(nèi)存模型可以選擇更合適的數(shù)據(jù)類型和編碼，更好的利用 Redis 內(nèi)存。
• 分析解決問題。當(dāng) Redis 出現(xiàn)阻塞、內(nèi)存占用等問題時，盡快發(fā)現(xiàn)導(dǎo)致問題的原因，便于分析解決問題。

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

Redis 內(nèi)存統(tǒng)計

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

在客戶端通過 redis-cli 連接服務(wù)器后（后面如無特殊說明，客戶端一律使用redis-cli），通過 info 命令可以查看內(nèi)存使用情況：info memory。

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

返回結(jié)果中比較重要的幾個說明如下：

used_memory

Redis 分配器分配的內(nèi)存總量（單位是字節(jié)），包括使用的虛擬內(nèi)存（即 swap）；Redis 分配器后面會介紹。used_memory_human 只是顯示更友好。

used_memory_rss

Redis 進程占據(jù)操作系統(tǒng)的內(nèi)存（單位是字節(jié)），與 top 及 ps 命令看到的值是一致的。

除了分配器分配的內(nèi)存之外，used_memory_rss 還包括進程運行本身需要的內(nèi)存、內(nèi)存碎片等，但是不包括虛擬內(nèi)存。

因此，used_memory 和 used_memory_rss，前者是從 Redis 角度得到的量，后者是從操作系統(tǒng)角度得到的量。

二者之所以有所不同，一方面是因為內(nèi)存碎片和 Redis 進程運行需要占用內(nèi)存，使得前者可能比后者小，另一方面虛擬內(nèi)存的存在，使得前者可能比后者大。

由于在實際應(yīng)用中，Redis 的數(shù)據(jù)量會比較大，此時進程運行占用的內(nèi)存與 Redis 數(shù)據(jù)量和內(nèi)存碎片相比，都會小得多。

因此 used_memory_rss 和 used_memory 的比例，便成了衡量 Redis 內(nèi)存碎片率的參數(shù)；這個參數(shù)就是 mem_fragmentation_ratio。

mem_fragmentation_ratio

內(nèi)存碎片比率，該值是 used_memory_rss / used_memory 的比值。

mem_fragmentation_ratio 一般大于 1，且該值越大，內(nèi)存碎片比例越大；mem_fragmentation_ratio<1，說明 Redis 使用了虛擬內(nèi)存，由于虛擬內(nèi)存的媒介是磁盤，比內(nèi)存速度要慢很多。

當(dāng)這種情況出現(xiàn)時，應(yīng)該及時排查，如果內(nèi)存不足應(yīng)該及時處理，如增加 Redis 節(jié)點、增加 Redis 服務(wù)器的內(nèi)存、優(yōu)化應(yīng)用等。

一般來說，mem_fragmentation_ratio 在 1.03 左右是比較健康的狀態(tài)（對于 jemalloc 來說）。

上面截圖中的 mem_fragmentation_ratio 值很大，是因為還沒有向 Redis 中存入數(shù)據(jù)，Redis 進程本身運行的內(nèi)存使得 used_memory_rss 比 used_memory 大得多。

mem_allocator

Redis 使用的內(nèi)存分配器，在編譯時指定；可以是 libc 、jemalloc 或者 tcmalloc，默認是 jemalloc；截圖中使用的便是默認的 jemalloc。

Redis 內(nèi)存劃分

Redis 作為內(nèi)存數(shù)據(jù)庫，在內(nèi)存中存儲的內(nèi)容主要是數(shù)據(jù)（鍵值對）；通過前面的敘述可以知道，除了數(shù)據(jù)以外，Redis 的其他部分也會占用內(nèi)存。

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

數(shù)據(jù)

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

Redis 使用鍵值對存儲數(shù)據(jù)，其中的值（對象）包括 5 種類型，即字符串、哈希、列表、集合、有序集合。

這 5 種類型是 Redis 對外提供的，實際上，在 Redis 內(nèi)部，每種類型可能有 2 種或更多的內(nèi)部編碼實現(xiàn)。

此外，Redis 在存儲對象時，并不是直接將數(shù)據(jù)扔進內(nèi)存，而是會對對象進行各種包裝：如 RedisObject、SDS 等；這篇文章后面將重點介紹 Redis 中數(shù)據(jù)存儲的細節(jié)。

進程本身運行需要的內(nèi)存

Redis 主進程本身運行肯定需要占用內(nèi)存，如代碼、常量池等等；這部分內(nèi)存大約幾兆，在大多數(shù)生產(chǎn)環(huán)境中與 Redis 數(shù)據(jù)占用的內(nèi)存相比可以忽略。

這部分內(nèi)存不是由 jemalloc 分配，因此不會統(tǒng)計在 used_memory 中。

補充說明：除了主進程外，Redis 創(chuàng)建的子進程運行也會占用內(nèi)存，如 Redis 執(zhí)行 AOF、RDB 重寫時創(chuàng)建的子進程。

當(dāng)然，這部分內(nèi)存不屬于 Redis 進程，也不會統(tǒng)計在 used_memory 和 used_memory_rss 中。

緩沖內(nèi)存

緩沖內(nèi)存包括客戶端緩沖區(qū)、復(fù)制積壓緩沖區(qū)、AOF 緩沖區(qū)等；其中，客戶端緩沖區(qū)存儲客戶端連接的輸入輸出緩沖；復(fù)制積壓緩沖區(qū)用于部分復(fù)制功能；AOF 緩沖區(qū)用于在進行 AOF 重寫時，保存最近的寫入命令。

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

內(nèi)存碎片

內(nèi)存碎片是 Redis 在分配、回收物理內(nèi)存過程中產(chǎn)生的。例如，如果對數(shù)據(jù)的更改頻繁，而且數(shù)據(jù)之間的大小相差很大，可能導(dǎo)致 Redis 釋放的空間在物理內(nèi)存中并沒有釋放。

但 Redis 又無法有效利用，這就形成了內(nèi)存碎片，內(nèi)存碎片不會統(tǒng)計在 used_memory 中。

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

如果 Redis 服務(wù)器中的內(nèi)存碎片已經(jīng)很大，可以通過安全重啟的方式減小內(nèi)存碎片：因為重啟之后，Redis 重新從備份文件中讀取數(shù)據(jù)，在內(nèi)存中進行重排，為每個數(shù)據(jù)重新選擇合適的內(nèi)存單元，減小內(nèi)存碎片。

Redis 數(shù)據(jù)存儲的細節(jié)

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

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

dictEntry：Redis 是 Key-Value 數(shù)據(jù)庫，因此對每個鍵值對都會有一個 dictEntry，里面存儲了指向 Key 和 Value 的指針；next 指向下一個 dictEntry，與本 Key-Value 無關(guān)。

Key：圖中右上角可見，Key（”hello”）并不是直接以字符串存儲，而是存儲在 SDS 結(jié)構(gòu)中。

RedisObject：Value(“world”)既不是直接以字符串存儲，也不是像 Key 一樣直接存儲在 SDS 中，而是存儲在 RedisObject 中。

實際上，不論 Value 是 5 種類型的哪一種，都是通過 RedisObject 來存儲的；而 RedisObject 中的 type 字段指明了 Value 對象的類型，ptr 字段則指向?qū)ο笏诘牡刂贰?/p>

不過可以看出，字符串對象雖然經(jīng)過了 RedisObject 的包裝，但仍然需要通過 SDS 存儲。

實際上，RedisObject 除了 type 和 ptr 字段以外，還有其他字段圖中沒有給出，如用于指定對象內(nèi)部編碼的字段。

jemalloc：無論是 DictEntry 對象，還是 RedisObject、SDS 對象，都需要內(nèi)存分配器（如 jemalloc）分配內(nèi)存進行存儲。

以 DictEntry 對象為例，有 3 個指針組成，在 64 位機器下占 24 個字節(jié)，jemalloc 會為它分配 32 字節(jié)大小的內(nèi)存單元。

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

jemalloc

Redis 在編譯時便會指定內(nèi)存分配器；內(nèi)存分配器可以是 libc 、jemalloc 或者 tcmalloc，默認是 jemalloc。

jemalloc 作為 Redis 的默認內(nèi)存分配器，在減小內(nèi)存碎片方面做的相對比較好。

jemalloc 在 64 位系統(tǒng)中，將內(nèi)存空間劃分為小、大、巨大三個范圍；每個范圍內(nèi)又劃分了許多小的內(nèi)存塊單位；當(dāng) Redis 存儲數(shù)據(jù)時，會選擇大小最合適的內(nèi)存塊進行存儲。

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

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

RedisObject

前面說到，Redis 對象有 5 種類型；無論是哪種類型，Redis 都不會直接存儲，而是通過 RedisObject 對象進行存儲。

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

RedisObject 的定義如下（不同版本的 Redis 可能稍稍有所不同）：

RedisObject 的每個字段的含義和作用如下：

type

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

當(dāng)我們執(zhí)行 type 命令時，便是通過讀取 RedisObject 的 type 字段獲得對象的類型；如下圖所示：

encoding

encoding 表示對象的內(nèi)部編碼，占 4 個比特。對于 Redis 支持的每種類型，都有至少兩種內(nèi)部編碼，例如對于字符串，有 int、embstr、raw 三種編碼。

通過 encoding 屬性，Redis 可以根據(jù)不同的使用場景來為對象設(shè)置不同的編碼，大大提高了 Redis 的靈活性和效率。

以列表對象為例，有壓縮列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis 傾向于使用壓縮列表進行存儲，因為壓縮列表占用內(nèi)存更少，而且比雙端鏈表可以更快載入。

當(dāng)列表對象元素較多時，壓縮列表就會轉(zhuǎn)化為更適合存儲大量元素的雙端鏈表。

通過 object encoding 命令，可以查看對象采用的編碼方式，如下圖所示：

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

lru

lru 記錄的是對象最后一次被命令程序訪問的時間，占據(jù)的比特數(shù)不同的版本有所不同（如 4.0 版本占 24 比特，2.6 版本占 22 比特）。

通過對比 lru 時間與當(dāng)前時間，可以計算某個對象的空轉(zhuǎn)時間；object idletime 命令可以顯示該空轉(zhuǎn)時間（單位是秒）。object idletime 命令的一個特殊之處在于它不改變對象的 lru 值。

lru 值除了通過 object idletime 命令打印之外，還與 Redis 的內(nèi)存回收有關(guān)系。

如果 Redis 打開了 maxmemory 選項，且內(nèi)存回收算法選擇的是 volatile-lru 或 allkeys—lru，那么當(dāng) Redis 內(nèi)存占用超過 maxmemory 指定的值時，Redis 會優(yōu)先選擇空轉(zhuǎn)時間最長的對象進行釋放。

refcount

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

當(dāng)創(chuàng)建新對象時，refcount 初始化為 1；當(dāng)有新程序使用該對象時，refcount 加 1；當(dāng)對象不再被一個新程序使用時，refcount 減 1；當(dāng) refcount 變?yōu)?0 時，對象占用的內(nèi)存會被釋放。

Redis 中被多次使用的對象(refcount>1)，稱為共享對象。Redis 為了節(jié)省內(nèi)存，當(dāng)有一些對象重復(fù)出現(xiàn)時，新的程序不會創(chuàng)建新的對象，而是仍然使用原來的對象。

這個被重復(fù)使用的對象，就是共享對象。目前共享對象僅支持整數(shù)值的字符串對象。

共享對象的具體實現(xiàn)：Redis 的共享對象目前只支持整數(shù)值的字符串對象。之所以如此，實際上是對內(nèi)存和 CPU（時間）的平衡：共享對象雖然會降低內(nèi)存消耗，但是判斷兩個對象是否相等卻需要消耗額外的時間。

對于整數(shù)值，判斷操作復(fù)雜度為 O(1)；對于普通字符串，判斷復(fù)雜度為 O(n)；而對于哈希、列表、集合和有序集合，判斷的復(fù)雜度為 O(n^2)。

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

就目前的實現(xiàn)來說，Redis 服務(wù)器在初始化時，會創(chuàng)建 10000 個字符串對象，值分別是 0~9999 的整數(shù)值；當(dāng) Redis 需要使用值為 0~9999 的字符串對象時，可以直接使用這些共享對象。

10000 這個數(shù)字可以通過調(diào)整參數(shù) REDIS_SHARED_INTEGERS（4.0 中是 OBJ_SHARED_INTEGERS）的值進行改變。

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

ptr

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

綜上所述，RedisObject 的結(jié)構(gòu)與對象類型、編碼、內(nèi)存回收、共享對象都有關(guān)系。

一個 RedisObject 對象的大小為 16 字節(jié)：4bit+4bit+24bit+4Byte+8Byte=16Byte。

SDS

Redis 沒有直接使用 C 字符串(即以空字符’\0’結(jié)尾的字符數(shù)組)作為默認的字符串表示，而是使用了 SDS。SDS 是簡單動態(tài)字符串(Simple Dynamic String)的縮寫。

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

SDS 的結(jié)構(gòu)如下：

其中，buf 表示字節(jié)數(shù)組，用來存儲字符串；len 表示 buf 已使用的長度；free 表示 buf 未使用的長度。

下面是兩個例子：

通過 SDS 的結(jié)構(gòu)可以看出，buf 數(shù)組的長度=free+len+1（其中 1 表示字符串結(jié)尾的空字符）。

所以，一個 SDS 結(jié)構(gòu)占據(jù)的空間為：free 所占長度+len 所占長度+ buf 數(shù)組的長度=4+4+free+len+1=free+len+9。

SDS 與 C 字符串的比較

SDS 在 C 字符串的基礎(chǔ)上加入了 free 和 len 字段，帶來了很多好處：

獲取字符串長度：SDS 是 O(1)，C 字符串是 O(n)。

緩沖區(qū)溢出：使用 C 字符串的 API 時，如果字符串長度增加（如 strcat 操作）而忘記重新分配內(nèi)存，很容易造成緩沖區(qū)的溢出。

而 SDS 由于記錄了長度，相應(yīng)的 API 在可能造成緩沖區(qū)溢出時會自動重新分配內(nèi)存，杜絕了緩沖區(qū)溢出。

修改字符串時內(nèi)存的重分配：對于 C 字符串，如果要修改字符串，必須要重新分配內(nèi)存（先釋放再申請），因為如果沒有重新分配，字符串長度增大時會造成內(nèi)存緩沖區(qū)溢出，字符串長度減小時會造成內(nèi)存泄露。

而對于 SDS，由于可以記錄 len 和 free，因此解除了字符串長度和空間數(shù)組長度之間的關(guān)聯(lián)，可以在此基礎(chǔ)上進行優(yōu)化。

空間預(yù)分配策略（即分配內(nèi)存時比實際需要的多）使得字符串長度增大時重新分配內(nèi)存的概率大大減小；惰性空間釋放策略使得字符串長度減小時重新分配內(nèi)存的概率大大減小。

存取二進制數(shù)據(jù)：SDS 可以，C 字符串不可以。因為 C 字符串以空字符作為字符串結(jié)束的標(biāo)識，而對于一些二進制文件（如圖片等）。

內(nèi)容可能包括空字符串，因此 C 字符串無法正確存取；而 SDS 以字符串長度 len 來作為字符串結(jié)束標(biāo)識，因此沒有這個問題。

此外，由于 SDS 中的 buf 仍然使用了 C 字符串（即以’\0’結(jié)尾），因此 SDS 可以使用 C 字符串庫中的部分函數(shù)。

但是需要注意的是，只有當(dāng) SDS 用來存儲文本數(shù)據(jù)時才可以這樣使用，在存儲二進制數(shù)據(jù)時則不行（’\0’不一定是結(jié)尾）。

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

Redis 在存儲對象時，一律使用 SDS 代替 C 字符串。例如 set hello world 命令，hello 和 world 都是以 SDS 的形式存儲的。

而 sadd myset member1 member2 member3 命令，不論是鍵（“myset”），還是集合中的元素（“member1”、 “member2”和“member3”），都是以 SDS 的形式存儲。

除了存儲對象，SDS 還用于存儲各種緩沖區(qū)。只有在字符串不會改變的情況下，如打印日志時，才會使用 C 字符串。

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

前面已經(jīng)說過，Redis 支持 5 種對象類型，而每種結(jié)構(gòu)都有至少兩種編碼。

這樣做的好處在于：一方面接口與實現(xiàn)分離，當(dāng)需要增加或改變內(nèi)部編碼時，用戶使用不受影響，另一方面可以根據(jù)不同的應(yīng)用場景切換內(nèi)部編碼，提高效率。

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

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

字符串

字符串是最基礎(chǔ)的類型，因為所有的鍵都是字符串類型，且字符串之外的其他幾種復(fù)雜類型的元素也是字符串，字符串長度不能超過 512MB。

內(nèi)部編碼

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

int：8 個字節(jié)的長整型。字符串值是整型時，這個值使用 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ù)據(jù)連在一起，尋找方便。

而 embstr 的壞處也很明顯，如果字符串的長度增加需要重新分配內(nèi)存時，整個 RedisObject 和 sds 都需要重新分配空間，因此 Redis 中的 embstr 實現(xiàn)為只讀。

raw：大于 39 個字節(jié)的字符串。

示例如下圖所示：

embstr 和 raw 進行區(qū)分的長度，是 39；是因為 RedisObject 的長度是 16 字節(jié)，sds 的長度是 9+ 字符串長度。

因此當(dāng)字符串長度是 39 時，embstr 的長度正好是 16+9+39=64，jemalloc 正好可以分配 64 字節(jié)的內(nèi)存單元。

編碼轉(zhuǎn)換

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

而對于 embstr，由于其實現(xiàn)是只讀的，因此在對 embstr 對象進行修改時，都會先轉(zhuǎn)化為 raw 再進行修改。

因此，只要是修改 embstr 對象，修改后的對象一定是 raw 的，無論是否達到了 39 個字節(jié)。

示例如下圖所示：

列表

列表（list）用來存儲多個有序的字符串，每個字符串稱為元素；一個列表可以存儲 2^32-1 個元素。

Redis 中的列表支持兩端插入和彈出，并可以獲得指定位置（或范圍）的元素，可以充當(dāng)數(shù)組、隊列、棧等。

內(nèi)部編碼

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

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

通過圖中可以看出，雙端鏈表同時保存了表頭指針和表尾指針，并且每個節(jié)點都有指向前和指向后的指針。

鏈表中保存了列表的長度；dup、free 和 match 為節(jié)點值設(shè)置類型特定函數(shù)。

所以鏈表可以用于保存各種不同類型的值，而鏈表中每個節(jié)點指向的是type為字符串的 RedisObject。

壓縮列表：壓縮列表是 Redis 為了節(jié)約內(nèi)存而開發(fā)的，是由一系列特殊編碼的連續(xù)內(nèi)存塊(而不是像雙端鏈表一樣每

文章題目：Redis為什么這么快？
鏈接URL：http://m.rwnh.cn/news38/105388.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、定制網(wǎng)站、品牌網(wǎng)站建設(shè)、手機網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)