Redis使用场景

Redis 作为一个非关系型数据库，除了在访问速度上拥有显著优势外，其本身支持的多种数据类型也非常有用，能覆盖系统开发中的很多应用场景。

使用建议

• Redis 速度快是建立在内存数据库基础上的，但是一台服务器的内存要比磁盘金贵许多，所以在项目初期不要想什么都往 Redis 里放，这样当数据量上来后很快内存就会不够用，反而得不偿失。合理的利用有限的内存，将读（写）频繁的热数据放在 Redis 中才能更好感受到它带来的性能提升；
• Redis 虽然提供了 RDB 和 AOF 两种持久化方式，但是普遍还是认为 Redis 的持久化并不是很靠谱。非常重要的数据不要依赖 Redis 来开发，或者最起码不要只在 Redis 中持久化；
• MySQL 经过不断优化性能已经非常好，所以 MySQL 提供的数据结构和访问效率能满足的需求的情况下不要引入 Redis，多引入一个组件就多一个可能的故障节点，尤其在保持数据一致性的场景中数据（比如用户余额）应该只放在数据库中，除非你知道怎么解决考系统的分布式事务。

1、热点数据的缓存

缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。

由于redis访问速度快、支持的数据类型比较丰富，所以redis很适合用来存储热点数据；另外redis提供了键过期功能，也提供了灵活的键淘汰策略，即可以结合expire，设置过期时间然后再进行缓存更新操作，这个功能最为常见，很多项目都有所运用。

2、限时业务的运用

Redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。

3、删除与过滤

我们可以使用LREM来删除评论。如果删除操作非常少，另一个选择是直接跳过评论条目的入口，报告说该评论已经不存在。

有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制，你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目，但Redis却能够使用非常少的内存来处理几百万条项目。

4、计数器相关问题

计数器的主要场景包括电商网站商品的浏览量、视频网站视频的播放数等。Redis提供的incrby等命令可以实现原子性的递增，性能很高，所以可以运用于高并发的秒杀活动、分布式序列号的生成，具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。

5、排行榜相关问题

关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet实现各种复杂的排行榜应用排序。

例如，我们需要展示各个部门的点赞排行榜， 所以可以针对每个部门做了一个SortedSet，然后以用户的openid作为上面的username,以用户的点赞数作为上面的score，然后针对每个用户做一个hash，通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息。

6、分布式会话

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

7、分布式锁

如今很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。

Redis中可以利用set功能来编写分布式的锁，如果这个操作返回 false，说明 key 的添加不成功，也就是当前有人在占用这把锁。而如果返回 true，则说明得了锁，便可以继续进行操作，并且在操作后通过 del 命令释放掉锁。并且即使程序因为某些原因并没有释放锁，由于设置了过期时间，该锁也会在 1 秒后自动释放，不会影响到其他程序的运行。

当然我们可以将这个特性运用于其他需要分布式锁的场景中，结合过期时间主要是防止死锁的出现。

8、延时操作

例如在订单生产后我们占用了库存，10分钟后去检验用户是够真正购买，如果没有购买将该单据设置无效，同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notifications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期， 我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。 当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。

9、分页、模糊搜索

redis的set集合中提供了一个zrangebylex方法，通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询，其中- +表示获取全部数据；通过zrangebylex key min max 可以返回字典区间的数据，利用这个特性可以进行模糊查询功能。

10、社交网络

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据。

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。 又或者在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。

11、最新列表

在Web应用中，“列出最新的回复”之类的查询非常普遍，这通常会带来可扩展性问题。这令人沮丧，因为项目本来就是按这个顺序被创建的，但要输出这个顺序却不得不进行排序操作。

类似的问题就可以用Redis来解决。Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

12、消息队列

Redis中list的数据结构实现是双向链表，所以可以非常便捷的应用于消息队列（生产者 / 消费者模型）。消息的生产者只需要通过LPUSH将消息放入list，消费者便可以通过rpop取出该消息，并且可以保证消息的有序性。如果需要实现带有优先级的消息队列也可以选择sortedset。而pub/sub 功能也可以用作发布者/订阅者模型的消息。无论使用何种方式，由于Redis拥有持久化功能，也不需要担心由于服务器故障导致消息丢失的情况。

13、时间轴

list作为双向链表，不光可以作为队列使用。如果将它用作栈便可以成为一个公用的时间轴。当用户发完微博后，都通过LPUSH将它存放在一个key为LATEST_WEIB 的list中，之后便可以通过lrange取出当前最新的微博。

14、循环链表

list还可以作为循环链表使用RPOPLPUSH source destination命令 RPOPLPUSH 在一个原子时间内，执行以下两个动作：

将列表 source 中的最后一个元素 (尾元素) 弹出，并返回给客户端。
将 source 弹出的元素插入到列表 destination ，作为 destination 列表的的头元素。
如果 source 和 destination 相同，则列表中的表尾元素被移动到表头，并返回该元素，可以把这种特殊情况视作列表的旋转 (rotation) 操作。

比如有个进程来完成派单任务，需要将用户发送过来的申请依次派发给工作人员，那么就可以把工作人员的身份标示维护在循环列表中，从列表尾部读取每次读取身份标示后相应的标示都会被放到列表头如此循环往复。

15、倒排索引

倒排索引是构造搜索功能的最常见方式，在 Redis 中也可以通过 set 进行建立倒排索引，这里以简单的拼音 + 前缀搜索城市功能举例：

假设一个城市北京，通过拼音词库将北京转为 beijing，再通过前缀分词将这两个词分为若干个前缀索引，有：北、北京、b、be…beijin 和 beijing。将这些索引分别作为 set 的 key（例如:index:北）并存储北京的 id，倒排索引便建立好了。接下来只需要在搜索时通过关键词取出对应的 set 并得到其中的 id 即可。