Redis模版到底有几种？带你一起慢慢了解和探索下

说到Redis模版，这个问题其实挺有意思的，因为它没有一个像官方说明书那样标准唯一的答案，我们通常说的“Redis模版”，并不是指Redis软件本身自带了一个叫“模版”的功能，而是指我们在使用Redis时，为了应对不同场景而形成的一些“套路”或者“最佳实践”，这就像做木工活儿，老师傅会告诉你，打柜子有打柜子的套路，做椅子有做椅子的方法，这些套路，就是我们说的“模版”。

如果我们从这个角度来数一数Redis模版到底有几种，那我们可以根据它们解决的核心问题,分成几个大类来慢慢了解。

第一类：缓存模版，这是Redis最出名、最常用的模版，可以说八成以上的人用Redis一开始都是为了它。

它的核心思想很简单，空间换时间”，网站或应用里有些数据，从数据库里查特别慢，比如商品的详情、用户的个人信息，那我们就在第一次查出来之后，顺手扔到Redis里，并设置一个过期时间（比如5分钟），接下来5分钟内，再有谁来查这个数据，我们就直接从Redis里拿，速度飞快，等5分钟时间一到，Redis自动把这条数据删掉，下次再有人查，系统又会去数据库取最新的数据，然后重新塞回Redis，这个过程，在程序员圈子里有几个非常经典的名字，Cache-Aside”（旁路缓存）模版（来源：微软云Azure架构中心的文章对此有详细阐述），这个模版的好处是，即使Redis这台机器突然宕机了，我们的应用也只是会慢一点，直接去查数据库，整个系统不会挂掉,比较健壮。

第二类：计数器与限流模版，这类模版利用了Redis处理数字“特别快”这个特点。

我们要统计一篇文章的阅读量，每次有人点击，我们就给Redis里一个叫 article:123:view_count 的键（key）执行一个 INCR 命令（让数字加1），这个操作是原子性的，也就是说即使一万人同时点击，这个数字也能准确无误地累加，不会出错，基于这个简单的计数器，我们可以衍生出更复杂的模版，限流”，想象一下，为了防止恶意攻击，我们想限制某个手机号一分钟内只能发送一次短信验证码，我们就可以这样做：当用户请求发送短信时，我们用一个键记录，rate_limit:13800138000，设置它的值为1，并让这个键在60秒后过期，一分钟内，如果这个用户再次请求，我们发现这个键已经存在，就拒绝发送，这就是一个非常简单的限流模版（来源：这种限流思路在《Redis实战》等书籍和高并发架构文章中广泛提及）。

第三类：排行榜模版，这个简直是Redis的杀手锏，因为它有一个叫“有序集合”（Sorted Set）的数据结构，天生就是干这个的。

比如做一个游戏积分榜，每个玩家得分和ID作为成员和分值存入有序集合，Redis瞬间就能给你按分数从高到低排好序，你随时可以查询第1到第10名的玩家是谁，或者查询某个玩家的具体排名，这个模版的应用非常广，除了游戏，还有热搜榜、销量榜等等，如果没有Redis，用数据库来实现实时变化的排行榜,性能压力会非常大。

第四类：会话存储模版，也就是常说的Session存储。

传统上，用户的登录状态（Session）是放在网站服务器内存里的，但一旦服务器重启或者用户下次请求被分配到另一台服务器，这个登录状态就丢了，用户就得重新登录，为了解决这个问题，大家就把Session统一存到一个地方，比如Redis里，这样，不管用户的请求被分配到哪台Web服务器，这台服务器都能去同一个Redis里验证用户的登录状态，实现了“分布式会话”,这是构建大型网站非常关键的一个模版。

第五类：消息队列模版，虽然Redis不是专业的消息队列软件（比如Kafka、RabbitMQ），但它凭借简单的列表（List）结构也能实现轻量级的队列功能。

它的基本模版是：一方（生产者）用 LPUSH 命令把任务消息塞进列表的左边，另一方（消费者）用 RPOP 命令从列表的右边取出任务进行处理，这样就形成了一个先进入的任务先被处理的队列（FIFO），这个模版适合用在不需要特别高可靠性的异步处理场景，比如发送通知邮件、清理临时文件等。

除了以上这五种比较核心和常见的模版，还有很多其他的“套路”，比如用“集合”（Set）实现的“标签系统”模版、用“地理空间索引”实现的“附近的人”模版等等。

回到最初的问题“Redis模版到底有几种？”，答案就是：没有一个确切的数字。 它更像是一套工具箱，里面有各种不同的工具（数据结构），而我们根据要解决的问题（业务场景），选择不同的工具组合成一种“用法”或“模式”，这就是我们所说的模版，了解和掌握这些模版，能帮助我们在设计系统时，更快地想到如何用Redis这把“瑞士军刀”来解决实际问题。