Redis作为当今最流行的内存数据库,已经成为服务端加速的必备工具之一。对于Redis为什么那么快?以及Redis采用单线程,但为什么反而获得更高的性能的疑问,在之前的Redis为什么那么快?一文中,已经有所介绍。

今天通过这篇,我们来了解一下Redis最常见的5种应用场景。您可以通过视频来学习,如果您不方便观看视频,也可以通过文字内容学习,文字部分做了更概要的总结。

缓存(Cache)

Redis的第一个应用场景是Redis作为缓存对象来加速Web应用的访问。

在该场景下,有一些存储于数据库中的数据会被频繁访问,如果频繁的访问数据库,数据库负载会升高,同时由于数据库IO比较慢,应用程序的响应会比较差。此时,如果引入Redis来存储这些被频繁访问的数据,就可以有效的降低数据库的负载,同时提高应用程序的请求响应。

会话存储(Session)

使用Redis来存储会话(Session)数据,可以实现在无状态的服务器之间共享用户相关的状态数据数据。

当用户登录Web应用时候,将会话数据存储于Redis,并将唯一的会话ID(Session ID)返回到客户端的Cookie中。当用户再向应用发送请求时,会将此会话ID包含在请求中。无状态的Web服务器,根据这个会话ID从Redis中搜索相关的会话数据来进一步请求处理。

这里需要注意的是,Redis是内存数据库,如果采用单实例部署。那么当Redis服务器故障重启之后,所有的Session会话会消失,用户不得不重新登录来获取新的Session。所以,当拿Redis来存储Session的时候,建议采用主从的集群模式来部署。这样,即使主服务器挂了,马上有从库接管流量,不影响用户的使用。

分布式锁(Distributed Lock)

当我们在应用中部署了多个节点,这些节点需要操作同一个资源的时候会存在竞争。此时,我们可以使用Redis来作为分布式锁,以协调多个节点对共享资源的操作。

这里主要是用Redis的原子操作命令:SETNX,该命令仅允许key不存在的时候才能设置key。

下图展示了一个简单用例。Client 1通过SETNX命令尝试创建lock 1234abcd。如果当前还没有这个key,那么将返回1。Client 1获得锁,就可以执行对共享资源的操作,操作完成之后,删除刚刚创建的lock(释放分布式锁)。如果Client 1在执行SETNX命令的时候,返回了0,说明有其他客户端占用了这key,那么等待一段时间(等其他节点释放)之后再尝试。

上面这个简单实现虽然可以满足很多用例,但它并不具备良好的容错机制。如果要在生产上是用的话,更推荐采用一些更高质量的分布式锁实现。比如,Java平台的话,可以选择:Redisson.

速率限制器(Rate Limiter)

由于Redis提供了计数器功能,所以我们可以通过该能力,配合超时时间,来实现速率限制器,最常见的场景就是服务端是用的请求限流。

一个基本的限速实现如下图:

根据用户id或者ip来作为key,使用INCR命令来记录用户的请求数量。然后将该请求数量与允许的请求上限数量做比较,只有低于限制的时候,才会执行请求处理。如果超过限制,就拒绝请求。

同时,请求数量的计数器需要设置一个时间窗口,比如:1分钟。也就是没过一分钟时间,计数器将被清零,重新计数。所以,当一个时间窗口中被限流之后,等到下一个时间窗口,就能恢复继续请求。以实现限制速率的效果。

除了时间窗算法之外,漏桶算法也能通过Redis来实现。

排行榜(Rank/Leaderboard)

由于Redis提供了排序集合(Sorted Sets)的功能,所以很多游戏应用采用Redis来实现各种排行榜功能。

排序集合是唯一元素(比如:用户id)的集合,每个元素按分数排序,这样可以快速的按分数来检索元素

小结

Redis的应用非常广泛,这里仅总结了一些常见的用法。除此之外,还有很多有意思的应用,这取决于业务场景。大家可以举一反三。

如果您平时也有上油管看前沿视频的话也可以装一个Youtube中文配音,它可以有效地提高学习效率。如果您因为网络原因不方便查看这些内容,也可以关注我的视频号「程序猿DD」或者B站频道,我会经常分享一些日常看到的精华学习资料,感兴趣的小伙伴根据自己平时习惯选择订阅即可。

欢迎关注我的公众号:程序猿DD。第一时间了解前沿行业消息、分享深度技术干货、获取优质学习资源