Redis实战系列(3) 使用hashtable和hash-max-zipmap-entries优化内存使用

在我的系统中大约有50000个用户，每个用户有nickname1、nickname2、nickname3、nickname4、profile_id。对于上面几个属性来说，每个用户都是唯一的，而用户信息大概有70个字段。我用user:info:$profile_id作为一个hashtable的key来存储一个用户的所有信息。而系统要求能用nickname1、nickname2、nickname3、nickname4来获取到用户信息。

最先考虑的是每个字段对应一个hashtable：user:nickname1:profile_id:map作为一个key，$email作为hashkey, $profile_id作为hashkey的值。对四个字段都做如是的处理，这样处理的内存占用量大概是15M，总共有4个hashtable，每个hashtable中有50000个元素，总共有200000个元素。

        下面先解释一下hash-max-zipmap-entries和hash-max-zipmap-value，然后再介绍第二种方案。

hash-max-zipmap-entries是只hashtable中元素的总个数不超过设定数量时，就用zipmap的方式来存储hashtable以节省内存

hash-max-zipmap-value是hashtable中的key以及value的长度小于设定的值时，就用zipmap的方式来存储hashtable以节省内存
一旦hashtable的元素个数超过了设定的值，或者任意一个元素的key或者value超过了hash-max-zipmap-value的值，则使用hashtable来存储。
这两个配置主要是减少了元数据。
    因为每个人的nickname1、nickname2、nickname3、nickname4都是全局唯一的，所以对每个人的nickname1、nickname2、nickname3、nickname4做md5，然后取前两位作为hashtable的可以，这样会有256个hashtable，然后hashtable中的key是nickname1、nickname2、nickname3、nickname4 值是profile_id，将200000个元素分布到256个槽中，每个槽平均有781.25个元素。把hash-max-zipmap-entries的数量设置为1000。而nickname1、nickname2、nickname3、nickname4和profile_id的长度是不会超过64个字节的，所以，经过这样处理之后，内存的使用量仅仅是4.7M左右。
     
    这样做的坏处是会多消耗一些cpu的时间，因为要遍历将近1000个元素的数量，不过这个代价是值得的。