Redis应用场景分析

在上一篇文章《Redis数据结构探究》中，对Redis的五种数据结构和它们的底层实现进行了分析，这篇文章主要结合近期应用Redis的经历，对Redis的使用场景做出分析。

在上篇文章中，简单总结了Redis有以下应用场景：

1、缓存服务

这是Redis应用最广泛的部分，用于减小数据库访问压力，提高系统并发量，逻辑也比较简单。

• select时，如redis中无此数据，则查询数据库并插入redis，如redis中有此数据，则直接返回。
• update时，先更新数据库，如redis中包含此数据，则更新redis。

2、SESSION服务器

用户的登录session数据一般是存储在数据库或单独的session服务器上，以便用户在访问集群应用时不会受到影响，而使用Redis来作为session存储方式的好处是：

• 存取速度快。
• 支持持久化。
• 可以查看实时用户数量。
  其中，支持持久化是比较重要的一点，因为部分系统比如购物网站会将购物车信息存储在session中，如不支持持久化可能会发生数据丢失。

3、消息队列

Redis提供的list可以很方便地提供push/pop操作，可以很容易实现消息队列，在以下应用场景应用较多：

• 对某些操作作异步处理，使用生产者消费者模式进行通信。
• 分布式系统中使用消息队列进行调度，实现应用解耦。
• 高并发情况下使用消息队列对请求流量削峰，将并发请求串行化，拒绝重复请求。
• 日志操作中使用消息队列解决多线程环境下日志操作的并发问题。

4、排行榜

Redis中的set是一个有序集合，有序集合的键是成员，而值是分值。这样既可以根据成员来访问元素，又可以根据分值来顺序访问元素结构。这样在实现排行榜功能时，向集合内插入元素就可以形成一个有序的集合，只要自定义分值来源，就可以实现排行榜功能，而不用每次进行排序。其他需要频繁排序的操作也可以使用，比如优先级队列等。

5、列表/时间轴

一些新闻网站/博客/微博等往往在首页需要一个时间排序的列表或时间轴，每次在生成时间轴时往往需要一个select order操作，请求时间较长且消耗性能，如果在redis中构建一个list,通过将数据不断push的方式，构建一个时序列表。
在微博系统中，个人feed流页和评论首页是通过这种方式存储的，可以显著地提升系统响应速度，并且减小数据库压力。

6、秒杀系统

在秒杀系统中，一般会有以下问题：

• 短时间内大量并发
• 并发读写时冲突严重，或产生错误。如果使用Mysql的行级锁，可能某些请求无法获取到锁，数据库负载过大时会导致宕机。
• 请求失败重复发送，有效请求少，耗费系统性能

使用Redis，可以解决这些问题，有如下方式。

• 过滤重复请求，以ip,参数，URL等记录请求，过滤一定时间内的客户端重复请求。
• 使用list记录请求，将请求顺序执行，并记录请求数量，如果有数量限制则拒绝超出数量外的请求。
• 不直接在数据库中扣减内存，而是将订单记录在list中，后续操作异步执行，并及时持久化到硬盘，防止内存数据丢失。
• 通过原子操作保证全局唯一id

7、标签操作

系统中一般会有标签、收藏等聚合操作，这类操作具有使用频率高，历史数据变动小的特性，一般我们不会给记录这类操作的不重要的字段添加索引，所以在查询时比较耗费性能，而使用Redis的set就可以解决这类问题，前几天给系统中的标签功能引入了索引，去掉了select * group by 这条查询。

• 用户标记某条数据时，将数据id存入标签id的set中
• 取消标记时，从set里移除该数据
• 查询时，直接取出set

8、计数器

上篇文章中说到了string类型可以存储字符串和浮点数，存储浮点数时可以进行自增操作，使用INCRBY可以保证原子递增，使用getset可以重置。可以用来记录访问次数，订单id等。另外，由于有过期时间，也可以实现黑名单等功能。

最近在使用Redis时，总结了一些技巧，比如可以利用Redis的主从复制特性搭建集群，像数据库分库一样将数据分实例存放，利用redis的多个库实现命名空间作用，而不是通过key或前缀。在进行查询时，因为redis访问需要网络io，可以利用hmget等方式一次获取多条数据，而不是单条单条地获取。合理设置value的大小。
本文对redis的使用场景进行了简单的总结，实际中会发现redis的使用能显著提升系统性能，应用也十分广泛，是后端开发的必备神器。

---

参考资料：
1、《Redis应用实战》
2、https://www.cnblogs.com/wajika/p/6625129.html
3、https://blog.youkuaiyun.com/bemavery/article/details/77448589