Redis应用场景
String–字符串
redis最能想到的就是使用序列化的字符串缓存,通常为json格式,把一些在mysql中需要大量sql查询操作和计算得到的数据缓存起来,再次访问的时候就可以直接读取数据,可有效降低数据库的压力,例如网站首页的某些排名信息,查询比较复杂,但是对实时性要求没那么高的,可以设置一个定时过期的缓存,这是最简单的缓存应用场景,redis提供了丰富的数据结构,可以用在很多web应用的场景。
Hash–哈希
哈希表是redis中很有用的数据结构,有时候我们需要存储结构话的数据,例如用户的登录信息
uid:1 // 用户uid
username:xxx // 用户名
age:18 // 年龄
head:xxx //头像
String模式
按照普通缓存的模式,存储这个结构需要先将其序列化,转换成json字符串,以user-uid
为键名,这样做有个问题,假如说现在需要修改head
字段,我需要经历如下步骤:
- 根据键名
user-1
获取到json
字符串 - 解析
json
- 修改结构体中的
head
字段 - 再次序列化成
json
-
set key
存储
Hash模式
接下来使用Hash
来存储,使用HMSET
命令存储所有字段
HMSET user-1 uid 1 username xxx age 18 head:xxx
这时候需要修改字段head
仅需一条命令即可:
HSET user-1 head zzz
相比之下是不是简单了很多,Hash模式
不仅操作大大简化,而且节省了String模式
中大量的序列化和反序列化的性能消耗。
List — 列表
List
在redis
中的应用也比较广泛,最典型的就是消息队列,在某些高并发场景下,由于mysql
存储介质为磁盘,在写入性能上由于磁盘的读写速度限制,它的写入速度可能达不到要求。但是redis
不一样,redis是完全基于内存数据库nosql
,没有I/O
瓶颈,写入和读取速度都非常快,这也是redis
流行的原因。假设现在要做一个商城的秒杀活动,在同一时刻必然会有大量的订单提交操作,mysql可能来不及写入,会导致其它用户阻塞,糟糕的情况下甚至系统奔溃,影响用户体验。在这种场景下就可以通过消息队列来处理,即:
- 先把提交的订单信息写入消息队列,可通过
LPUSH
和RPOP
命令实现入队
和出队
的操作。 - 通过异步程序将订单存储到
mysql
另一种场景是可作为IM
聊天系统的timeline
模型,即每个用户对应一个timeline
模型,根据时间顺序排列,每个用户通过timeline
获取消息
Set — 集合
集合和List
的类似,区别是集合是可以自动排重的,且集合是无序的。例如:存储某个用户的所有粉丝和所有的好友等。
Sorted Set 有序集合
有序集合根据score
字段来排序,通过ZADD
可添加一个有序集合,例如:
ZADD page_rank 10 google.com
上面命令的意思是在page_rank
集合中添加字符串google.com
,score
为10
。
有序集合可用来数据分页,例如我们查询用户积分前100名的用户,每页20条展示,通过
ZRANGE key start stop [WITHSCORES]
命令可实现分页,时间复杂度为O(log(N)+M)
,
在数据量大,查询比较耗时,可大大提高web的性能。
Pub/Sub — 发布 / 订阅
发布订阅模式通过发布和订阅发送和接收消息,例如A和B订阅(subscribe
)了频道news.it
,这时候C向改频道发送(publish
)一条信息hello
,这时候A和B会收到这条消息,这就是最简单的发布订阅模式,A和B也可以订阅别的频道,可以接受来自不同频道的信息,注意这里的A和B是长连接,PUBSUB CHANNELS
命令可查看当前活跃的频道。这个功能最典型应用就是IM
系统,广播等场景,但是redis
发布和订阅没有确认的过程,消息发出就没了,不管有没有收到,在实际场景中可能会选择别的方案。