Redis最常见的5种应用场景

2023-10-04 00:35 由程序猿DD 发表于 #后端开发

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。第一时间了解前沿行业消息、分享深度技术干货、获取优质学习资源