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
