Redis 内存考虑

1. 只要有可能的话，就尽量使用散列键而不是字符串键来储存键值对数据，因为散列键管理方便、能够避免键名冲突、并且还能够节约内存。具体实例： 节约内存：Instagram的Redis实践 blog.nosqlfan.com/html/3379.html
2. 如果将redis作为cache进行频繁读写和超时删除等，此时应该避免设置较大的k-v，因为这样会导致redis的 内存碎片增加，导致rss占用较大，最后被操作系统OOM killer干掉。一个很具体的issue例子请见：https://github.com/antirez/redis/issues/2136
3. 如果采用序列化考虑通用性，请采用json相关的库进行处理，如果对内存大小和速度都很关注的，推荐使用messagepack进行序列化和反序列化
4. 如果需要计数器，请将计数器的key通过天或者小时分割，比如下边的设计:

　6.需要修改为：

　7.更好的一个设计是采用hash：

　8.各种数据结构及其占用内存的benchmark测试

set个数	每个set的元素总数	内存占用	Key大小	Value大小
100	100	1.88M	7	36
100	1000	10.75M	7	36
100	10000	111.12M	7	36
1000	100	11.59M	8	36
1000	1000	100.35M	8	36
1000	10000	1.08G	8	36
10000	100	108.71M	9	36
10000	1000	996.23M	9	36

zset个数	每个zset的元素总数	内存占用	Key大小	Value大小
100	100	1.62M	8	49
100	1000	15.91M	8	49
100	10000	162.06M	8	49
1000	100	8.71M	9	49
1000	1000	151.87M	9	49
1000	10000	1.58G	9	49
10000	100	79.83M	10	49
10000	1000	1.48G	10	49

hash个数	每个hash的元素总数	内存占用	Key大小	Value大小
100	100	1.63M	8	49
100	1000	6.29M	8	49
100	10000	156.91M	8	49
1000	100	8.71M	9	49
1000	1000	55.59M	9	49
1000	10000	1.52G	9	49
10000	100	79.83M	10	49
10000	1000	548.58M	10	49

list个数	每个list的元素总数	内存占用	Key大小	Value大小
100	100	1.23M	8	36
100	1000	10.00M	8	36
100	10000	92.40M	8	36
1000	100	4.83M	9	36
1000	1000	92.52M	9	36
1000	10000	916.47M	9	36
10000	100	40.76M	10	36
10000	1000	917.69M	10	36

string个数	内存占用	Key大小	Value大小
100	846.79K	13	36
1000	966.29K	13	36
10000	2.16M	13	36
100000	130.88M	13	36