场景:
关系服务，负责维护用户的关注关系，粉丝关系，如微博中的关注关系，其中使用redis HASH结构维护用户的粉丝关系
结构如图下:
问题：
对于业务场景需要查询A,B,C,D是否为E的粉丝，HASH结构效率最高。现实中遇到的问题是，对于大V用户有千万粉丝时，缓存失效后load操作
时间太长，通过后台日志，一个20w粉丝的主播，loadDB数据至缓存需要1s以上，要知道，这期间，redis可是不响应任何其他请求的。
优化:
redis层优化：
首先先浏览了一下redis的源码，解压包后，查看src目录下的t_hash.c
hmset操作，则是我调用的方法，查看可知，内部是循环调用hashTypeSet，将应用端传进去的批量key-value逐个添加，
除此之外，系统会对目前hash结构引用的type类型进行判定，来选择合适的编码规则，redis hash有两种编码，ziplist,
hash_table,当存入key-value字节长度少于64，并且hash内size少于512时，redis会使用ziplist存储，反之会使用hash_table
做存储。
其中
hashTypeTryConversion方法校验key-value是否过长，
hashTypeSet插入key-value时，会检测容器容量，当容量大于hash_max_ziplist_entries时，
会做类型转换操作。默认的配置为:
hash容量扩充，与rehash，由代码可知，当初始容量为0时，会取系统配置
DICT_HT_INITIAL_SIZE做初始化，当容量满了时，会取当前已用容量2倍来做初始化。
dictExpand做扩容操作，dict结构体维护着两个table 一个代表扩容前，一个代表扩容后，扩容时
扩容后的table则为ht[1].
笔者通过修改hash扩容时的配置，使得不是使得当前容量2倍进行扩容，而是直接每次扩容增加20w，这样的话，笔者的30w粉丝数，大约进行两次扩容即可。比之前由4开始的初始容量进行扩容会减少7次左右的扩容操作。
不过还是无法解决问题，redis基于内存级的扩容没有我们想象中那么慢，至少修改后，对于30w的量只有数十毫秒级的优化，对于秒级的时间总量，这点优化远远不够。所以笔者放弃了此种方法。
