位级别和字级别的操作
Redis 2.2引入了位级别和字级别的操作: GETRANGE, SETRANGE, GETBIT 和 SETBIT.使用这些命令，你可以把redis的字符串当做一个随机读取的（字节）数组。例如你有一个应用，用来标志用户的ID是连续的整数，你可以使用一个位图标记用户的性别，使用1表示男性，0表示女性，或者其他的方式。这样的话，1亿个用户将仅使用12 M的内存。你可以使用同样的方法，使用 GETRANGE 和 SETRANGE 命令为每个用户存储一个字节的信息。这仅是一个例子，实际上你可以使用这些原始数据类型解决更多问题。
尽可能使用散列表（hashes）
存储的内容很少的散列表能高效利用内存。所以比如你的系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面.
当散列表非常小的时候，我们采用将数据encode为一个O(N)的数据结构，你可以认为这是一个带有长度属性的线性数组。只有当N是比较小的时候，才会采用这种encode，这样使用HGET和HSET命令的复杂度仍然是O(1)：当散列表包含的元素增长太多的时候，散列表将被转换为正常的散列表（极限值可以在redis.conf进行配置）.
尽管从时间复杂度或常量时间的角度来看，采用这种encode理论上都不会有多大性能提升，但是，一个线性数组通常会被CPU的缓存更好的命中（线性数组有更好的局部性）,从而提升了访问的速度.
设置redis:
hash-max-ziplist-entries 512 hash-max-ziplist-value 1024
内存分配
maxmemory的值可以在配置文件中设置，或者在启动后通过 ConFIG SET 命令设置(see Using memory as an LRU cache for more info).
如果 maxmemory 没有设置，redis就会一直向OS申请内存，直到OS的所有内存都被使用完。所以通常建议设置上redis的内存限制，当redis的内存达到内存限制后，再向redis发送写指令，会返回一个内存耗尽的应用程序错误，但是不会导致整台机器宕掉.
