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中，迁移结束后，内存会被回收并释放其内存。
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。