redis 中存数据时，到底什么时候用  hset 相比于 set 存数据时又有什么不一样？

set 就是普通的已key-value 方式存储数据，可以设置过期时间。时间复杂度为 O(1)，没多执行一个 set 在redis 中就会多一个 key ，

hset 则是以hash 散列表的形式存储。超时时间只能设置在 大 key 上，单个 filed 则不可以设置超时 时间复杂度我百度了很多文章都说是 O(1) 但是我下面给出的参考文章说时间上的时间复杂度其实是 O(N) N 值是单个hash 上的 filed 个数，所以 hash 上单个不适合存储大量的 filed 并且如果 filed 多了比较消耗cpu，但同时以 散列表存储则比较节省内存。

所以在实际的使用过程中应该使用 set 存储单个大文本非结构化数据 hset 则存储结构化数据，一个 hash 存储一条数据，一个 filed 则存储 一条数据中的一个属性，value 则是属性对应的值。

例如 数据库中有一张表 user 包含  id,name,age,sex 4个属性，并且有400w条数据，

      id,name,age,sex

1、1，张三，16，1

2、2，李四，22，1

3、3，王五，28，0

4、4，赵六，32，1

…

如果要整表缓存到 redis 中则使用 hash ，一条数据一个hash 一个hash 里则包含4个filed。

hset user_1 id 1 name 张三 age 16 sex 1

hset user_2 id 2 name 李四 age 16 sex 1

…

这样存储，如果用户的某个属性值改变，还可以单个修改。

例如 吧张三的年龄改为30 则可以使用命令：  hset user_1 age 30

为啥要使用hash呢？

我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，也就是说，Key仍然是用户ID,value是一个Map，这个Map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field),也就是通过 key(用户ID) + field(属性标签)就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。