redis 数据类型的使用场景

value为对应的数据类型。

String

应用场景:
String是最常用的一种数据类型,普通的key/value存储都可以归为此类,value其实不仅是String,也可以是数字。

Hash

应用场景:
我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:
用户ID,为查找的key,
存储的value用户对象包含姓名name,年龄age,生日birthday 等信息,
如果用普通的key/value结构来存储,主要有以下2种存储方式:
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,
如:set u001 "李三,18,20010101"
这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,
如:mset user:001:name "李三 "user:001:age18 user:001:birthday "20010101"
虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap
并提供了直接存取这个Map成员的接口,
如:hmset user:001 name "李三" age 18 birthday "20010101"
也就是说,Key仍然是用户ID,value是一个Map,这个Map的key是成员的属性名,value是属性值,
这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过
key(用户ID) + field(属性标签) 操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。

List

Set

实现方式:
set 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

http://blog.csdn.net/gaogaoshan/article/details/41039581/

Redis中,并不是所有的数据都一直存储在内存中的,这是和Memcached相比一个最大的区别
Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,hash等数据结构的存储
原文地址:https://www.cnblogs.com/ydxblog/p/5674060.html