Redis 存储结构体信息，选 hash 还是string（） java

在讲到使用hash还是string存储的选择前，先了解Redis的hash和string结构。
以下资料引自老钱的Redis深度历险。
string string和hash都是Redis的一种数据结构。string结构常用来缓存用户信息，通常将用户信息结构体使用JSON序列化成字符串，然后将序列化后的字符串存入Redis进行缓存。

文章图片

Redis的字符串是动态字符串，可以修改，内部结构类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配。如上图锁实，内部为当前字符串实际分配的空间capacity，一般高于实际字符串长度len。使用的指令有set, get, mset, mget等
hash Redis的hash相当于Java的HashMap,内部结构实现与HashMap一致，即数组+链表结构

文章图片

不过Redis的hash的值只能是字符串，rehash方式不一样，为了提高性能，Redis保留新旧两个hash结构，采用渐进式rehash策略，查询时会同事查询两个hash结构，在后续的定时任务中以及hash操作指令中，循序渐进将旧hash的内容迁移到xinhash中，直至完全取代旧hash。hash移除最后一个元素后会自动被删除，内存被回收。
前面说到string适合存储用户信息，而hash结构也可以存储用户信息，不过是对每个字段单独存储，因此可以在查询时获取部分字段的信息，节省网络流量。
因此就引出了这篇文章，存储结构体信息是用hash还是string？
以下信息出自StackOverflow Redis strings vs Redis hashes to represent JSON: efficiency?

I want to store a JSON payload into redis. There's really 2 ways I can do this:1. One using a simple string keys and values.key:user, value:payload (the entire JSON blob which can be 100-200 KB)SET user:1 payload2. Using hashesHSET user:1 username "someone"HSET user:1 location "NY"HSET user:1 bio "STRING WITH OVER 100 lines"Keep in mind that if I use a hash, the value length isn't predictable. They're not all short such as the bio example above.Which is more memory efficient? Using string keys and values, or using a hash?

该用户也是同样的疑问，因为值的长度是不确定的，所以不知道采用string还是hash存储更有效率
这个问题底下有个开发者回答的非常好，这里翻译出来供大家一起学习讨论，如果有更好的方案，欢迎提出来首先，答者建议参考redis官方的内存优化的文章：https://redis.io/topics/memory-optimization，用来理解官方的开发者是内存优化方面基于什么考虑。
之后，答者列出了四个方案并给出了各个方案的利弊
1. 存储整个对象，其中JSON序列化过的字符串作为key

INCR id:users SET user:{id} '{"name":"Fred","age":25}' SADD users {id}

优势：可以认为是“最佳实践”，因为每个对象都是全特性的key，JSON解析特别块，尤其是一次性查询很多个字段的时候
劣势：如果只查询一个字段，速度就显得比较慢了

2. 在hash中存储每个对象的属性

INCR id:users HMSET user:{id} name "Fred" age 25 SADD users {id}

优势：这也可以认为是最佳时间。每个对象都是一个全特性的key。不需要解析JSON字符串
劣势：如果要查询对象的全部字段会比较慢。嵌套类型的对象（即对象里面还包着对象）无法轻易存储

3. 将对象转化为JSON字符串，用hash结构存储

INCR id:users HMSET users {id} '{"name":"Fred","age":25}'

这个方案可以仅用两个key，不需要很多key。但是没法对每个用户对象设置TTL(Time to Live，剩余生存时间)，因为对象仅仅是hash中的一个字段，而不是全特性的key

优势：JSON解析很快，尤其是一次查询多个字段时，对主key的命名空间污染更少
劣势：如果要存储很多对象，那么内存使用和方案1相当。当只需要查询一个字段时，会比方案2速度慢。答者不认为这是一个“最佳实践”

4. 存储对象的每个属性作为单独的key

INCR id:users SET user:{id}:name "Fred" SET user:{id}:age 25 SADD users {id}

根据上面的文章，即redis内存优化，这个方案不推荐（除非对象的属性需要专门设置TTL或者别的设置）

优势：对象的属性是全特征key，对于应用来说比较好处理
劣势：慢，内存消耗更大，不是一个“最佳实践”。对主key的命名空间有很大污染

总的来说，方案4是最不推荐的，方案1和方案2非常相似，也很常见。答者更推荐方案1，因为这个方案允许存储更复杂的对象（也就是说对象可以有很多层嵌套）。方案3通常用在对命名空间比较有要求的场景下，比如说不想要太多key，不关心TTL等参数。
参考资料
《Redis深度历险》
https://juejin.im/book/5afc2e...
https://stackoverflow.com/que...
原文链接：https://blog.csdn.net/u010145...
版权声明：本文为CSDN博主「布鲁斯1990」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
近期热文推荐：
1.1,000+ 道 Java面试题及答案整理(2022最新版)
2.劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.别再写满屏的爆爆爆炸类了，试试装饰器模式，这才是优雅的方式！！
5.《Java开发手册（嵩山版）》最新发布，速速下载！
【Redis 存储结构体信息，选 hash 还是string（）】觉得不错，别忘了随手点赞+转发哦！