Redis 內(nèi)存優(yōu)化
使用特殊編碼方式存儲聚合數(shù)據(jù)類型
從 Redis 2.2 開始，很多數(shù)據(jù)結(jié)構(gòu)的占用空間優(yōu)化到低于一個確定的閾值。 對于 Hash ，List ， 由數(shù)字組成的 Set ， Sorted Set，當(dāng)元素個數(shù)低于一個配置的Length且每個元素的大小小于一個配置的Size 的時候，這些數(shù)據(jù)結(jié)構(gòu)會以一種非常搞笑的編碼方式進行保存，占用空間將縮小到小于原來的十分之一。
這些優(yōu)化對于用戶和API都是透明的，因為這個是CUP和內(nèi)存級別上的優(yōu)化，用戶對此沒有任何感知。上面提到的Length 和 Size 都是可配置的，在 redis.conf 里面，如下
hash-max-zipmap-entries 512 (hash-max-ziplist-entries for Redis >= 2.6)
hash-max-zipmap-value 64 (hash-max-ziplist-value for Redis >= 2.6)
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512
如果一個特殊的值重新編碼之后會大于配置值，那么Redis會自動轉(zhuǎn)換到以普通的編碼方式來保存。這種方式對較小的值是非常快的，但是如果你想要用在大元素上面，建議你要測試一遍普通方式和特殊編碼方式的時間比較在確定是否要這么做。
使用32位的Redis實例
由于32位的指針很小，所以使用32位的Redis在存儲Key上面會節(jié)省很多內(nèi)存。但是這樣每個實例的最大內(nèi)存就被局限在4GB 以內(nèi)。 使用 make 32bit 命令來安裝 32位的Redis，RDB和AOF 文件都是兼容32位和64位的，所以不用擔(dān)心在32位的Redis實例中生產(chǎn)的RDB何AOF文件不能再64位實例中恢復(fù)數(shù)據(jù)。
位和字節(jié)級別的操作
從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命令進行數(shù)據(jù)遍歷也是非常高效的。
盡可能地使用Hash
盡可能的將你的數(shù)據(jù)模型抽象到一個散列表里面。比如你的web系統(tǒng)中有一個用戶對象，不要為這個用戶的名稱，姓氏，郵箱，密碼設(shè)置單獨的key,而是應(yīng)該把這個用戶的所有信息存儲到一張散列表里面.
我做過測試了，確實單獨的Key內(nèi)存占用會大好多，但是一般沒人會用單獨的Key吧。用json字符串作為Value和用hash差別不大
使用散列結(jié)構(gòu)高效存儲抽象的鍵值對
這節(jié)我怎樣都看不懂啊 TAT
