Redis应用场景浅析

Redis应用场景

String–字符串

redis最能想到的就是使用序列化的字符串缓存,通常为json格式,把一些在mysql中需要大量sql查询操作和计算得到的数据缓存起来,再次访问的时候就可以直接读取数据,可有效降低数据库的压力,例如网站首页的某些排名信息,查询比较复杂,但是对实时性要求没那么高的,可以设置一个定时过期的缓存,这是最简单的缓存应用场景,redis提供了丰富的数据结构,可以用在很多web应用的场景。

Hash–哈希

哈希表是redis中很有用的数据结构,有时候我们需要存储结构话的数据,例如用户的登录信息

uid:1 // 用户uid
username:xxx // 用户名
age:18 // 年龄
head:xxx //头像

String模式

按照普通缓存的模式,存储这个结构需要先将其序列化,转换成json字符串,以user-uid为键名,这样做有个问题,假如说现在需要修改head字段,我需要经历如下步骤:

  1. 根据键名user-1获取到json字符串
  2. 解析json
  3. 修改结构体中的head字段
  4. 再次序列化成json
  5. 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 — 列表

Listredis中的应用也比较广泛,最典型的就是消息队列,在某些高并发场景下,由于mysql存储介质为磁盘,在写入性能上由于磁盘的读写速度限制,它的写入速度可能达不到要求。但是redis不一样,redis是完全基于内存数据库nosql,没有I/O瓶颈,写入和读取速度都非常快,这也是redis流行的原因。假设现在要做一个商城的秒杀活动,在同一时刻必然会有大量的订单提交操作,mysql可能来不及写入,会导致其它用户阻塞,糟糕的情况下甚至系统奔溃,影响用户体验。在这种场景下就可以通过消息队列来处理,即:

  1. 先把提交的订单信息写入消息队列,可通过LPUSHRPOP命令实现入队出队的操作。
  2. 通过异步程序将订单存储到mysql

另一种场景是可作为IM聊天系统的timeline模型,即每个用户对应一个timeline模型,根据时间顺序排列,每个用户通过timeline获取消息

Set — 集合

集合和List的类似,区别是集合是可以自动排重的,且集合是无序的。例如:存储某个用户的所有粉丝和所有的好友等。

Sorted Set 有序集合

有序集合根据score字段来排序,通过ZADD可添加一个有序集合,例如:

ZADD page_rank 10 google.com

上面命令的意思是在page_rank集合中添加字符串google.comscore10
有序集合可用来数据分页,例如我们查询用户积分前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发布和订阅没有确认的过程,消息发出就没了,不管有没有收到,在实际场景中可能会选择别的方案。

    原文作者:metmax
    原文地址: https://www.jianshu.com/p/1288bc9322f7
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞