Redis 內存優化
使用特殊編碼方式存儲聚合數據類型
從 Redis 2.2 開始，很多數據結構的占用空間優化到低于一個確定的閾值。 對于 Hash ，List ， 由數字組成的 Set ， Sorted Set，當元素個數低于一個配置的Length且每個元素的大小小于一個配置的Size 的時候，這些數據結構會以一種非常搞笑的編碼方式進行保存，占用空間將縮小到小于原來的十分之一。
這些優化對于用戶和API都是透明的，因為這個是CUP和內存級別上的優化，用戶對此沒有任何感知。上面提到的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會自動轉換到以普通的編碼方式來保存。這種方式對較小的值是非常快的，但是如果你想要用在大元素上面，建議你要測試一遍普通方式和特殊編碼方式的時間比較在確定是否要這么做。
使用32位的Redis實例
由于32位的指針很小，所以使用32位的Redis在存儲Key上面會節省很多內存。但是這樣每個實例的最大內存就被局限在4GB 以內。 使用 make 32bit 命令來安裝 32位的Redis，RDB和AOF 文件都是兼容32位和64位的，所以不用擔心在32位的Redis實例中生產的RDB何AOF文件不能再64位實例中恢復數據。
位和字節級別的操作
從Redis 2.2開始，Redis提供了GETRANGE/SETRANGE/GETBIT/SETBIT四個用于字符串類型Key/Value的命令。通過這些命令，我們便可以像操作數組那樣來訪問String類型的值數據了。比如唯一標識用戶身份的ID，可能僅僅是String值的其中一段子字符串。這樣就可以通過GETRANGE/SETRANGE命令來方便的提取。再有就是可以使用BITMAP來表示用戶的性別信息，如1表示male，0表示female。用這種方式來表示100,000,000個用戶的性別信息時，也僅僅占用12MB的存儲空間，與此同時，在通過SETBIT/GETBIT命令進行數據遍歷也是非常高效的。
盡可能地使用Hash
盡可能的將你的數據模型抽象到一個散列表里面。比如你的web系統中有一個用戶對象，不要為這個用戶的名稱，姓氏，郵箱，密碼設置單獨的key,而是應該把這個用戶的所有信息存儲到一張散列表里面.
我做過測試了，確實單獨的Key內存占用會大好多，但是一般沒人會用單獨的Key吧。用json字符串作為Value和用hash差別不大
使用散列結構高效存儲抽象的鍵值對
這節我怎樣都看不懂啊 TAT
