4.4 内存考虑

  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通过天或者小时分割，比如下边的设计:
    内存考虑 - 图1

    需要修改为：
    内存考虑 - 图2

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

    内存考虑 - 图3

  5. 各种数据结构及其占用内存的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