redis五种数据结构如下：

 

1.String 字符串类型

是redis中最基本的数据类型，一个key对应一个value。

String类型是二进制安全的，意思是 redis 的 string 可以包含任何数据。如数字，字符串，jpg图片或者序列化的对象。

2.Hash （哈希）

是一个Mapmap，指值本身又是一种键值对结构，如 value={{field1,value1},......fieldN,valueN}}

3.链表 (List)

List 说白了就是链表（redis 使用双端链表实现的 List），是有序的，value可以重复，可以通过下标取出对应的value值，左右两边都能进行插入和删除数据。

4.Set 集合

集合类型也是用来保存多个字符串的元素，但和列表不同的是集合中 1. 不允许有重复的元素，2.集合中的元素是无序的，不能通过索引下标获取元素，3.支持集合间的操作，可以取多个集合取交集、并集、差集。

5.zset 有序集合

有序集合和集合有着必然的联系，保留了集合不能有重复成员的特性，区别是，有序集合中的元素是可以排序的，它给每个元素设置一个分数，作为排序的依据。

应用场景

String应用场景

 

 

1. 单值缓存

Set Key Value

Get Key

2. 对象缓存

1.Set user:1 value (json格式数据)

2.MSet user:1:name guajia use:1:balance 1888

MGet user1:name user:1:balance

3. 分布式锁：

3.1 分布式运用场景一【下单减库存】

 

如图标红的部分，如果是单体架构 我们一般是这样来实现减库存操作的 但是在高并发的互联网公司这样做，就会造成“超卖”的现象。所以就需要redis来实现分布式锁

如上图标记SETNX命令 它只会存入一个不存在的键值对，如果不会改变原来的key所存入的值，返回结果为0

SETNX product:10001 true //返回1代表获取锁成功 返回0代表获取锁失败---》 执行业务操作

 

如果setnx 命令返回0 直接扔给前端后端服务正忙 请稍后重试】 DEL product:10001 //执行完业务用它来释放锁

SET product:10001 true ex 10 nx //防止程序意外终止而导致死锁

3.2 分布式运用场景二

 

INCR 命令 每次执行 所存储的key的值 数量加1 (如果用数据库的话 需要考虑并发和加锁) 【注：redis是个单线程应用程序 这样不会导致高并发的脏读,主从的redis 在后面会使用分布式锁，一般单体的redis并发量在9-10万左右 】

 

3.3 分布式运用场景三 【 Web集群的session 共享 】

原理是把原有的Tomcat存储用户信息转为redis 把用户的信息 序列化后 存入redis。

3.4 分布式运用场景四【 分布式系统全局序列号 】

INCRBY orderId 1000 // redis 批量生成序列号提升性能

如项目使用 分库分表 ，就可以使用这个 ，目的是让主键ID 在都是唯一的 ，这个在实际场景非常重要。

使用INCRBY orderId 1000 （这个命令是一次生成1000个订单id 供下次生成订单使用）

Hash应用场景

 

大家仔细看 Hset key field value 比string多出来了一个field

 

 

Hash应用场景一 【电商购物车】

 

 

如图先示刚加入购物车的商品使用 hset cart:1001 10088 1,啥意思 cart代表的购物车 当然这个key 你可以随意定 但是意义要让所有人清楚，:1001 这里代表的是用户id，后面的10088 代表的是商品id。

第二步 点击 购物车的增加商品按钮 可以使用hincrby 命令 对已有值进行增量操作

有人可能会问，如果减少加购数量？骚年 你太年轻了 可以把增量的值调为-1 那每次就是减1

获取购物车商品总数 hlen cart:1001 [这边把商品id去掉就行了 前提是你所有的加购设置key 和field的格式是一样的 不然查出来的数量肯定不对] //它返回的是key下的所有field数量

涉及删除商品，使用删除的命令 hdel cart:1001 10088

获取加购商品的总数量 使用hgetall cart:1001 //它返回的key下的所有键值，可以把所有的值加起来就是加购商品总数量

 

hash的优点 缺点

 

hash的会分配槽位，集群中 会导致数据过于集中，没办法做分片。

List应用场景

 

仔细看命令前缀 有L 和R 分别代表左和右。

常用的数据结构

 

栈: LPUSH +LPOP = > 放进去的数据放在左边 导致最后放进去的元素处于栈顶 最先的元素是处于栈底 使用LPOP 取值【或称移除值】是先从最左侧【栈顶】取值的 符合 先进后出的规则 【FILO】

队列： 与上面相反 取值时是使用RPOP 是 移除值是从最右侧开始的 所有最后进入的会被取出 符合 队列的先进先出的规则【FIFO】

**BLOCKIng MQ(阻塞队列) **: = LPUSH　＋BRPOP [这个就是一个消息队列 ，消息队列中有个发送者 和 接受者 ]

BRPOP 就是从key列表尾弹出一个元素，如果列表中没有元素，就会一直处于阻塞等待多少秒，后面又会循环地执行 直到取到元素为止

运用的场景一 【微博和公众号的消息流】

 

如微博你关注了1000个大V 每个大V 一天放两条数据 ，有1亿用户 。那么数据量有多大。可能有几百M的数据。 如果使用数据库 查询效率那就不是很高了

比如 你关注了小明和小红。

小明发了一条消息： 使用 LPUSH msg:小明Id 消息Id 小红发了一条消息： 使用 LPUSH msg:小红Id 消息Id

查看最新的微博消息： 使用LRANGE msg:小红Id 0 4 这个就是从左侧取下标是0到4的消息 意味着是取小红发的最新的5条消息的消息ID 进而从缓存里面取出对应的消息内容

SET应用场景

 

常见命令

 

运用的场景一 【微信抽奖】

 

1.参与抽奖： SADD key 用户id ： 参与了用户的id

2.查看参与抽奖的又会: SMEMBERS key

3. 抽取n名中奖者

方式一：DMEMBER key [count]

方式二： SPOP key [count]

方式一和方式二的运用常见是 方式一 只有中奖单一 没有多次抽奖和设置奖品等级。因为方式一 每次执行不会把抽取的数据删掉，后面执行还可能会抽取到原来的用户

[ SRANDMEMBER key [count] 返回集合中一个或多个随机数]

 

ps: like:{消息ID} 就是 key {用户ID} 是 member

运用的场景三【微信微博关注模型】

 

SDIFF set1 set2 set3 是以 set1为基准 秋 与set2和set3的并集 的差集

[得到a是set2和set3的并集中所没有的】

关注模型：

1.你关注的人

set guanzhu:我的id {张三、李四、王五、小明、程咬金}

2.小明关注的人

set guanzhu:小明的id {张三、赵六、尼古拉斯}

3.程咬金关注的人

set guanzhu:程咬金的id {小明、李四}

4.我和小明的共同关注：

SINTER guanzhu:我的id guanzhu:小明的id

得到就是 张三

5.我关注的人也在关注他 【我关注的某人 否也请关注小明】

SISMEMBER guanzhu:程咬金的id 小明的ID

SISMEMBER guanzhu:张三的id 小明的ID

SISMEMBER //判断 member 元素是否是集合 key 的成员

6.我可能认识的人

SDIFF guanzhu:小明的id 我的ID