开发设计规范 - 内存考虑
只要有可能的话，就尽量使用散列键而不是字符串键来储存键值对数据，因为散列键管理方便、能够避免键名冲突、并且还能够节约内存。
具体实例： 节约内存：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大小 |
|---|---|---|---|---|
| 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 |