简单介绍使用Redis时可用的内存优化策略
从2.2版本开始，许多数据类型经过内存优化。像hash，list和仅由整数和有序集合组成的set，当小于给定的元素数量，到达到最大元素大小时，会以非常节省内存的方式进行编码，使得占用的内存最多减少10倍（平均节省5倍），这一过程对用户完全透明。可以调整redis.conf里的如下配置，来调整特殊编码类型的最大元素数量和最大元素大小，也就是说在配置的范围内，该元素集合会采用非常节省的内存方式进行编码：
如果某个特殊编码值超过配置的最大值，Redis会自动将其转换成正常编码，这个转换过程对于简单值很快，但如果是较大的聚合类型，建议运行基准测试来检查转换时间是否符合需求。
当Redis被编译为32位实例时，指针变小（通常的64位实例，指针对象都是8byte，32位实例，指针对象变小为4byte），它的每个键使用的内存更少，缺点是最大内存使用量将被限制在4GB，RDB和AOF在32位和64位实例之间相关兼容，所以从32位切换到64位或者反过来都没有问题
Redis2.2引入 , , 和 这些bit和byte级别的操作，能够让我们将Redis的string类型视为随机访问数组的效果（数组的随机访问时间复杂度O(1)）。这在某些特定场景下有非常不错的表现，比如某个用户订阅功能里，用户由唯一的渐进整数标识，那么可以用bitmap保存订阅了的用户列表（或者未订阅的），对于有1亿用户来说，只需12MB的内存即可保存，这里设置记录使用到bit操作。
1MB=1024KB=1024000Byte=8192000
12MB等于98304000，约等于1亿
首先，多个key使用的内存空间比单个key多个字段的hash要占用更多的内存；其次，在前面介绍过，在hash比较小时，会采用特殊编码缩小占用的内存，这种编码结构像的线性数组，它的时间复杂度O(N)，但在小集合时，它仍能将HGET和HSET命令的时间复杂度维持在O(1)，从时间复杂度看效果不错，另外线性数组的结构是有利于CPU缓存。所以如果缓存对象或者存在关联字段的问题模型，使用hash是非常合适的。
另外，对于简单K-V，比如小的html片段，string-boolean或者string-string等，可以通过拆分重新分配处理来使用hash结构，例如：
HSET KEY FIELD VALUE 原始：object:1234 hash：HSET object:12 34 somevalue 原始：object:2 hash：HSET obejct 2 somevalue
一个现实使用hash节省内存的例子万金油的String，为什么不好用了。需要注意的是，每当hash超过配置指定的元素数或者元素大小，它将转换为真的hashtable结构，并失去节省的内存。
hash里的字段不能独立设置过期时间，所以如果有这方面的要求，可能需要调整。
Redis最多能分配的内存大小为maxmemory配置的值，当达到这个值后，写命令会失败，读命令正常，如果没有设置maxmemory，Redis会尝试继续按其认为合理的方式分配内存（使用虚拟内存），性能会急剧下降，因此建议配置一些相关限制。关于Redis的内存分配，需要注意的几点：
- 删除的Key所占用的内存，并不总是立刻向OS释放内存，这是由于内存分配器没法释放内存，比如删除的Key与其他没有删除的Key在同一个page cache上，这时RSS（Resident Set Size）表现为维持现有值，但Redis里记录使用内存是降低的
- 内存分配器会尝试重用先前释放的内存，RSS表现为平稳且没有增长
- Redis所需要的内存需要根据峰值决定，而非平均值
- 当峰值远大于当前使用的内存值时，碎片率的值变得不可靠（碎片率=RSS/mem_used，mem_used表示Redis分配的总和）