阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 blog.csdn.net/u010145219/article/details/99427693 「布鲁斯1990」欢迎转载，保留摘要，谢谢！

string
hash

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

在讲到使用hash还是string存储的选择前，先了解Redis的hash和string结构。

以下资料引自老钱的Redis深度历险

string

string和hash都是Redis的一种数据结构。string结构常用来缓存用户信息，通常将用户信息结构体使用JSON序列化成字符串，然后将序列化后的字符串存入Redis进行缓存。

String数据结构

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

hash

Redis的hash相当于Bash的HashMap,内部结构实现与HashMap一致，即数组+链表结构

hash数据结构

不过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:

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 payload

Using hashes

HSET 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存储结构体信息，选hash还是string？

string

hash