Redis教程(十四)：內(nèi)存優(yōu)化介紹
一、特殊編碼：
自從Redis 2.2之后，很多數(shù)據(jù)類型都可以通過特殊編碼的方式來進(jìn)行存儲空間的優(yōu)化。其中，Hash、List和由Integer組成的Sets都可以通過該方式來優(yōu)化存儲結(jié)構(gòu)，以便占用更少的空間，在有些情況下，可以省去9/10的空間。
這些特殊編碼對于Redis的使用而言是完全透明的，事實上，它只是CPU和內(nèi)存之間的一個交易而言。如果內(nèi)存使用率方面高一些，那么在操作數(shù)據(jù)時消耗的CPU自然要多一些，反之亦然。在Redis中提供了一組配置參數(shù)用于設(shè)置與特殊編碼相關(guān)的各種閾值，如：
#如果Hash中字段的數(shù)量小于參數(shù)值，Redis將對該Key的Hash Value采用特殊編碼。
hash-max-zipmap-entries 64
#如果Hash中各個字段的最大長度不超過512字節(jié)，Redis也將對該Key的Hash Value采用特殊編碼方式。
hash-max-zipmap-value 512
#下面兩個參數(shù)的含義基本等同于上面兩個和Hash相關(guān)的參數(shù)，只是作用的對象類型為List。
list-max-ziplist-entries 512
list-max-ziplist-value 64
#如果set中整型元素的數(shù)量不超過512時，Redis將會采用該特殊編碼。
set-max-intset-entries 512
倘若某個已經(jīng)被編碼的值再經(jīng)過修改之后超過了配置信息中的最大限制，那么Redis會自動將其轉(zhuǎn)換為正常編碼格式，這一操作是非?？焖俚?，但是如果反過來操作，將一個正常編碼的較大值轉(zhuǎn)換為特殊編碼，Redis的建議是，在正式做之前最好先簡單測試一下轉(zhuǎn)換效率，因為這樣的轉(zhuǎn)換往往是非常低效的。
二、BIT和Byte級別的操作：
從Redis 2.2開始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四個用于字符串類型Key/Value的命令。通過這些命令，我們便可以像操作數(shù)組那樣來訪問String類型的值數(shù)據(jù)了。比如唯一標(biāo)識用戶身份的ID，可能僅僅是String值的其中一段子字符串。這樣就可以通過GETRANGE/SETRANGE命令來方便的提取。再有就是可以使用BITMAP來表示用戶的性別信息，如1表示male，0表示female。用這種方式來表示100,000,000個用戶的性別信息時，也僅僅占用12MB的存儲空間，與此同時，在通過SETBIT/GETBIT命令進(jìn)行數(shù)據(jù)遍歷也是非常高效的。
三、盡可能使用Hash：
由于小的Hash類型數(shù)據(jù)占用的空間相對較少，因此我們在實際應(yīng)用時應(yīng)該盡可能的考慮使用Hash類型，比如用戶的注冊信息，這其中包括姓名、性別、email、年齡和口令等字段。我們當(dāng)然可以將這些信息以Key的形式進(jìn)行存儲，而用戶填寫的信息則以String Value的形式存儲。然而Redis則更為推薦以Hash的形式存儲，以上信息則以Field/Value的形式表示。
現(xiàn)在我們就通過學(xué)習(xí)Redis的存儲機(jī)制來進(jìn)一步證明這一說法。在該篇博客的開始處已經(jīng)提到了特殊編碼機(jī)制，其中有兩個和Hash類型相關(guān)的配置參數(shù)：hash-max-zipmap-entries和hash-max-zipmap-value。至于它們的作用范圍前面已經(jīng)給出，這里就不再過多的贅述了?，F(xiàn)在我們先假設(shè)存儲在Hash Value中的字段數(shù)量小于hash-max-zipmap-entries，而每個元素的長度又同時小于hash-max-zipmap-value。這樣每當(dāng)有新的Hash類型的Key/Value存儲時，Redis都會為Hash Value創(chuàng)建定長的空間，最大可預(yù)分配的字節(jié)數(shù)為:
total_bytes = hash-max-zipmap-entries * hash-max-zipmap-value
這樣一來，Hash中所有字段的位置已經(jīng)預(yù)留，并且可以像訪問數(shù)組那樣隨機(jī)的訪問Field/Value，他們之間的步長間隔為hash-max-zipmap-value。只有當(dāng)Hash Value中的字段數(shù)量或某一新元素的長度分別超過以上兩個參數(shù)值時，Redis才會考慮將他們以Hash Table的方式進(jìn)行重新存儲，否則將始終保持這種高效的存儲和訪問方式。不僅如此，由于每個Key都要存儲一些關(guān)聯(lián)的系統(tǒng)信息，如過期時間、LRU等，因此和String類型的Key/Value相比，Hash類型極大的減少了Key的數(shù)量(大部分的Key都以Hash字段的形式表示并存儲了)，從而進(jìn)一步優(yōu)化了存儲空間的使用效率。
相關(guān)文章
Redis中的大Key問題指的是某些鍵（key）所對應(yīng)的值（value）特別大或集合類數(shù)據(jù)結(jié)構(gòu)中元素數(shù)量過多,大Key會導(dǎo)致讀取成本高、寫操作易阻塞、慢查詢和主從同步異常等問題,本文就來介紹一下如何解決,感興趣的可以了解一下2024-09-09
在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時間，衡量的標(biāo)準(zhǔn)是在多長時間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)，Redis中，實現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和cluster集群，感興趣的同學(xué)可以閱讀本文2023-04-04
Redis使用單線程的原因就是多線程并不能有效提升Redis的性能，相反可能還會降低性能，所以自然而然使用單線程,本文給大家詳細(xì)介紹了Redis為什么是單線程的，感興趣的朋友跟隨小編一起看看吧2023-06-06
本文主要給大家介紹了windows下通過批處理腳本啟動redis的操作,windows下redis啟動,需要進(jìn)入redis安裝目錄,然后shift+右鍵,選擇“在此處打開命令窗口”,然后輸入redis-server.exe redis.conf,就可以啟動redis了,文中有詳細(xì)的圖文參考,感興趣的朋友可以參考下2023-12-12
這篇文章主要介紹了Linux 下redis5.0.0安裝教程，本文圖文并茂給大家介紹的非常詳細(xì)，具有一定的參考借鑒價值,需要的朋友可以參考下2019-10-10
這篇文章主要介紹了Redis中的慢日志，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-12-12
這篇文章主要介紹了Redis實現(xiàn)分布式鎖和等待序列的方法示例，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2019-06-06
這篇文章主要介紹了redis啟動失敗問題之完美解決方案,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-09-09
很多人都遇到過這么一道面試題：Redis是單線程還是多線程？這個問題既簡單又復(fù)雜,說他簡單是因為大多數(shù)人都知道Redis是單線程,說復(fù)雜是因為這個答案其實并不準(zhǔn)確,本文就給大家講講Redis單線程架構(gòu)的優(yōu)勢與不足,需要的朋友可以參考下2024-02-02
Redis數(shù)據(jù)結(jié)構(gòu)原理淺析
這篇文章主要為大家介紹了Redis數(shù)據(jù)結(jié)構(gòu)原理淺析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-02-02