Redis存储结构体信息,选hash还是String

Redis的Hash与String的结构

一、String

String与Hash都是Redis的一种数据结构。String常用来缓存用户信息，通常将用户信息结构体用json序列化成字符串，再将该字符串存入redis中。

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

补充：Redis的数据结构有：String、Hash、集合（set）、有序集合（storted set）、列表（list）

二、Hash

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

 注意：redis的hash的值只能是字符串，rehash方式不一样，为了提高性能，Redis仍旧保留两种Hash结构，采用渐进式rehash策略。（浅谈Redis中Hash的渐进式rehash策略_玲珑骰子安红豆，入骨相思知不知-CSDN博客）。会同时查询两个hash结构，在后续的定时任务中以及hash操作指令中会循序渐进的将旧hash内容迁移到新hash中，迁移结束后，内存会被回收并释放其内存。

rehash：说白了rehash就是将容器进行扩容，重新调整位置，而Java中的HashMap数组扩容是将所有的元素重新散列；Redis的rehash操作是将数组元素缓慢的迁移到新的数组中，Redis和Java的扩容机制是一样的。由于redis是单线程并发安全的所以不能大量有阻塞现象。Redis采用多路复用技术

多路：指可以进行多个网络连接

复用：使用一个线程执行任务

String适合存储用户信息，hash也可以存储，两者的区别在于，String是存储整个用户对象，而hash则可以存储用户的字段（每个字段单独存储），因此查询时可以只获取部分字段，节省网络流量。

如果值的长度不确定，不知道选择hash还是String，已经有高人提供了四种解决方案：

1.存储整个对象，将json序列化后的字符串作为key

INCR id:users

SET user:{id} '{"name":"张三","age":25}'

SADD users {id}

 优势：可以认为是“最佳实践”，每个对象都是全特性的key，json解析特别快，尤其是一次性查询多个字段的时候。

劣势：如果查询一个字段，效率就下来了。

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

INCR id：users

HMSET user:{id}  name "张三"  age  25

SADD users {id}

 优势：这个可以认为是最佳时间。每个对象都是一个全特性的key，不需要解析json字符串

劣势：但是要查询对象的全部字段会比较慢，既嵌套类型对象（就是对象里面包着对象）无法轻易存储。

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

INCR id:users

HMSET users {id} '{"name":"张三","age":23}'

 这个方案可以仅仅用两个key，不需要很多key。但是无法对每个对象设置TTL（Time to live，剩余生命周期），由于对象仅仅是hash中的一个字段，而不是全特性的key

优势：json解析快，体现在查询多个字段时，对主key的命名空间污染少

劣势：当存储多个对象时，内存使用和方案一相当，查询多个字段时，速度会比方案二慢。

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

INCR  id:users

SET user:{id}:name "张三"

SET user:{id}:age 25

SADD users {id}

 按照官方文章，即redis内存优化，不建议使用这种方法（除非对象的属性需要专门设置TTL或者别的设置）

优势：对象的属性是全特性的key，对于应用来说比较好处理

劣势：慢，内存消耗更大，对命名空间污染很大

总结：方案四不建议使用，方案一与方案二相似，比较常见，力荐方案一，该方案可以存储更复杂的对象（可以实现对象嵌套）。方案三通常用在对生命周期空间比较有要求的场景下，例如：不太关心TTL等参数，不要太多的key。