只要有可能的话，就尽量使用散列键而不是字符串键来储存键值对数据，因为散列键管理方便、能够避免键名冲突、并且还能够节约内存。
具体实例： 节约内存：Instagram的Redis实践 blog.nosqlfan.com/html/3379.html
如果将redis作为cache进行频繁读写和超时删除等，此时应该避免设置较大的k-v，因为这样会导致redis的 内存碎片增加，导致rss占用较大，最后被操作系统OOM killer干掉。一个很具体的issue例子请见：https://github.com/antirez/redis/issues/2136
如果采用序列化考虑通用性，请采用json相关的库进行处理，如果对内存大小和速度都很关注的，推荐使用messagepack进行序列化和反序列化
如果需要计数器，请将计数器的key通过天或者小时分割，比如下边的设计:
需要修改为：
更好的一个设计是采用hash：
各种数据结构及其占用内存的benchmark测试
set个数每个set的元素总数内存占用Key大小Value大小1001001.88M736100100010.75M73610010000111.12M736100010011.59M83610001000100.35M8361000100001.08G83610000100108.71M936100001000996.23M936 zset个数每个zset的元素总数内存占用Key大小Value大小1001001.62M849100100015.91M84910010000162.06M84910001008.71M94910001000151.87M9491000100001.58G9491000010079.83M10491000010001.48G1049 hash个数每个hash的元素总数内存占用Key大小Value大小1001001.63M84910010006.29M84910010000156.91M84910001008.71M9491000100055.59M9491000100001.52G9491000010079.83M1049100001000548.58M1049 list个数每个list的元素总数内存占用Key大小Value大小1001001.23M836100100010.00M8361001000092.40M83610001004.83M9361000100092.52M936100010000916.47M9361000010040.76M1036100001000917.69M1036 string个数内存占用Key大小Value大小100846.79K13361000966.29K1336100002.16M1336100000130.88M1336 Redis开发运维实践指南 本文为《Redis开发运维实践指南》内容，该书作者为黄鹏程，已授权云栖社区转载。