一、特殊編碼：
自從Redis 2.2之后，很多數(shù)據(jù)類(lèi)型都可以通過(guò)特殊編碼的方式來(lái)進(jìn)行存儲(chǔ)空間的優(yōu)化。其中，Hash、List和由Integer組成的Sets都可以通過(guò)該方式來(lái)優(yōu)化存儲(chǔ)結(jié)構(gòu)，以便占用更少的空間，在有些情況下，可以省去9/10的空間。
這些特殊編碼對(duì)于Redis的使用而言是完全透明的，事實(shí)上，它只是CPU和內(nèi)存之間的一個(gè)交易而言。如果內(nèi)存使用率方面高一些，那么在操作數(shù)據(jù)時(shí)消耗的CPU自然要多一些，反之亦然。在Redis中提供了一組配置參數(shù)用于設(shè)置與特殊編碼相關(guān)的各種閾值，如：
復(fù)制代碼 代碼如下:
#如果Hash中字段的數(shù)量小于參數(shù)值，Redis將對(duì)該Key的Hash Value采用特殊編碼。
hash-max-zipmap-entries 64
#如果Hash中各個(gè)字段的最大長(zhǎng)度不超過(guò)512字節(jié)，Redis也將對(duì)該Key的Hash Value采用特殊編碼方式。
hash-max-zipmap-value 512
#下面兩個(gè)參數(shù)的含義基本等同于上面兩個(gè)和Hash相關(guān)的參數(shù)，只是作用的對(duì)象類(lèi)型為L(zhǎng)ist。
list-max-ziplist-entries 512
list-max-ziplist-value 64
#如果set中整型元素的數(shù)量不超過(guò)512時(shí)，Redis將會(huì)采用該特殊編碼。
set-max-intset-entries 512
倘若某個(gè)已經(jīng)被編碼的值再經(jīng)過(guò)修改之后超過(guò)了配置信息中的最大限制，那么Redis會(huì)自動(dòng)將其轉(zhuǎn)換為正常編碼格式，這一操作是非?？焖俚模侨绻催^(guò)來(lái)操作，將一個(gè)正常編碼的較大值轉(zhuǎn)換為特殊編碼，Redis的建議是，在正式做之前最好先簡(jiǎn)單測(cè)試一下轉(zhuǎn)換效率，因?yàn)檫@樣的轉(zhuǎn)換往往是非常低效的。
二、BIT和Byte級(jí)別的操作：
從Redis 2.2開(kāi)始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四個(gè)用于字符串類(lèi)型Key/Value的命令。通過(guò)這些命令，我們便可以像操作數(shù)組那樣來(lái)訪問(wèn)String類(lèi)型的值數(shù)據(jù)了。比如唯一標(biāo)識(shí)用戶(hù)身份的ID，可能僅僅是String值的其中一段子字符串。這樣就可以通過(guò)GETRANGE/SETRANGE命令來(lái)方便的提取。再有就是可以使用BITMAP來(lái)表示用戶(hù)的性別信息，如1表示male，0表示female。用這種方式來(lái)表示100,000,000個(gè)用戶(hù)的性別信息時(shí)，也僅僅占用12MB的存儲(chǔ)空間，與此同時(shí)，在通過(guò)SETBIT/GETBIT命令進(jìn)行數(shù)據(jù)遍歷也是非常高效的。
三、盡可能使用Hash：
由于小的Hash類(lèi)型數(shù)據(jù)占用的空間相對(duì)較少，因此我們?cè)趯?shí)際應(yīng)用時(shí)應(yīng)該盡可能的考慮使用Hash類(lèi)型，比如用戶(hù)的注冊(cè)信息，這其中包括姓名、性別、email、年齡和口令等字段。我們當(dāng)然可以將這些信息以Key的形式進(jìn)行存儲(chǔ)，而用戶(hù)填寫(xiě)的信息則以String Value的形式存儲(chǔ)。然而Redis則更為推薦以Hash的形式存儲(chǔ)，以上信息則以Field/Value的形式表示。
現(xiàn)在我們就通過(guò)學(xué)習(xí)Redis的存儲(chǔ)機(jī)制來(lái)進(jìn)一步證明這一說(shuō)法。在該篇博客的開(kāi)始處已經(jīng)提到了特殊編碼機(jī)制，其中有兩個(gè)和Hash類(lèi)型相關(guān)的配置參數(shù)：hash-max-zipmap-entries和hash-max-zipmap-value。至于它們的作用范圍前面已經(jīng)給出，這里就不再過(guò)多的贅述了?，F(xiàn)在我們先假設(shè)存儲(chǔ)在Hash Value中的字段數(shù)量小于hash-max-zipmap-entries，而每個(gè)元素的長(zhǎng)度又同時(shí)小于hash-max-zipmap-value。這樣每當(dāng)有新的Hash類(lèi)型的Key/Value存儲(chǔ)時(shí)，Redis都會(huì)為Hash Value創(chuàng)建定長(zhǎng)的空間，最大可預(yù)分配的字節(jié)數(shù)為:
total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value
這樣一來(lái)，Hash中所有字段的位置已經(jīng)預(yù)留，并且可以像訪問(wèn)數(shù)組那樣隨機(jī)的訪問(wèn)Field/Value，他們之間的步長(zhǎng)間隔為hash-max-zipmap-value。只有當(dāng)Hash Value中的字段數(shù)量或某一新元素的長(zhǎng)度分別超過(guò)以上兩個(gè)參數(shù)值時(shí)，Redis才會(huì)考慮將他們以Hash Table的方式進(jìn)行重新存儲(chǔ)，否則將始終保持這種高效的存儲(chǔ)和訪問(wèn)方式。不僅如此，由于每個(gè)Key都要存儲(chǔ)一些關(guān)聯(lián)的系統(tǒng)信息，如過(guò)期時(shí)間、LRU等，因此和String類(lèi)型的Key/Value相比，Hash類(lèi)型極大的減少了Key的數(shù)量(大部分的Key都以Hash字段的形式表示并存儲(chǔ)了)，從而進(jìn)一步優(yōu)化了存儲(chǔ)空間的使用效率。
您可能感興趣的文章:- redis內(nèi)存空間效率問(wèn)題的深入探究
- redis 限制內(nèi)存使用大小的實(shí)現(xiàn)
- redis 使用lettuce 啟動(dòng)內(nèi)存泄漏錯(cuò)誤的解決方案
- 淺談內(nèi)存耗盡后Redis會(huì)發(fā)生什么
- 一次關(guān)于Redis內(nèi)存詭異增長(zhǎng)的排查過(guò)程實(shí)戰(zhàn)記錄
- 淺談redis內(nèi)存數(shù)據(jù)的持久化方式
- 內(nèi)存型數(shù)據(jù)庫(kù)Redis持久化小結(jié)
- 降低PHP Redis內(nèi)存占用
- 詳解Redis瘦身指南
