陆拾贰號聊到后端技术栈，Redis是绕不开的一个组件。不管是刚入行的新人，还是在分布式系统里摸爬滚打多年的老手，都会在日常开发中频繁跟它打交道。早年间它只是作为缓存层出现，后来慢慢变成分布式锁、消息队列、排行榜、布隆过滤器，甚至向量检索的载体，成了业务系统里承担“加速”和“解耦”的关键角色。这套东西能活了十几年，而且生命力越来越强，背后的优势和特点非常值得系统梳理一遍。
这篇内容我会从底层设计、典型场景、实操部署、面试考点这几个维度展开，尽量把“Redis凭什么能撑起这么多种用法”讲透。适合正在学Redis的初学者，也适合准备面试、或者想把现有业务里Redis用得更扎实的开发者。
1. Redis的优势到底是什么：先看底层设计
很多文章一上来就罗列Redis的优势清单，比如高性能、高并发、支持持久化、支持集群等等，听着很空。我更喜欢从设计层面去理解它，因为所有表面上的“优势”都是有底层机制支撑的。明白了这些，你在实际使用中才不会用错方向。
1.1 内存存储与常数级复杂度：快不是玄学
Redis最直观的优势就是快。官方数据里，单实例读写能力可以到10万次/秒以上，我在生产环境压测过，普通的8核16G机器上，纯内存操作轻松能跑出12万+的读请求。这个速度的根基就是“数据在内存里”。
很多初学者会把Redis和Memcached放在一起比较。Memcached虽然也快，但支持的数据结构有限，断电即丢，基本只能做纯缓存。Redis不一样，它不仅快，还能把内存里的数据按你指定的策略持久化到磁盘。这个“内存+持久化”的组合，让它的定位从“缓存工具”上升成了“数据存储服务”。
这里还要提一个容易被忽略的点：Redis的核心操作大多是O(1)复杂度。比如GET、SET、LPUSH、SADD这些指令，不管你的key有100个还是有1000万个，单次操作的耗时都稳定在微秒级。这就是为什么在热点数据的读取场景里，它可以毫秒级甚至微秒级响应，这是传统数据库走索引也比不了的。
但是，快也伴随代价。内存是昂贵资源，Redis的容量受到物理内存限制。所以生产环境通常只放热点数据、中间结果、状态数据，不能把它当成主数据库去存全量业务数据。
1.2 单线程模型：被误解的“瓶颈”反而是优势
“Redis是单线程的”，这句话在面试里经常被拿出来问，但很多人理解偏了。
Redis 6.0之前，命令执行确实是单线程模型，但不是全程单线程。它的网络IO在Redis 6.0之后已经支持多线程，真正串行的只是命令执行环节。也就是说，多个客户端可以同时发请求，但Redis服务端是一条一条按顺序执行命令的。
为什么这个设计反而是优势？核心原因有几个：
第一，避免了多线程环境下的竞争问题。不需要加锁，没有线程上下文切换开销，性能稳定可预期。对于内存操作来说，单线程处理简单指令的吞吐已经足够高。
第二，保证了原子性。因为命令是串行执行的，单个命令天然原子，不需要额外的事务控制。像INCR、DECR这种自增操作，在并发环境下也不会出现超卖问题。这也是Redis能实现分布式锁的基础之一。当然，如果你需要多条命令一起原子执行，可以用Lua脚本或MULTI/EXEC事务，原理同样是利用单线程串行执行。
第三，简化了底层实现，让持久化、复制这些功能在实现上更可控。你可以设想一下，如果Redis是多线程执行命令，RDB快照、AOF重写这些过程中就要考虑数据一致性锁问题，复杂度会高一个量级。
不过单线程模型也有它的“命门”：如果某条命令执行时间过长，它就会阻塞后面所有命令。生产环境最典型的两个坑，一是使用KEYS命令去匹配大量key，二是对一个包含百万元素的big key执行SORT或SPOP等操作。这些问题在后面实操部分我会专门展开。
1.3 五种基础数据类型与扩展结构：一个数据库顶几个工具
“数据类型丰富”是Redis另一个核心优势。新手刚开始可能只用了String和Hash，但等你把List、Set、ZSet这些都用顺手之后，会发现很多业务逻辑根本不需要额外引入中间件。
| 类型 | 底层实现 | 典型场景 | 核心命令 |
|---|---|---|---|
| String | SDS动态字符串 | 缓存、计数器、分布式锁 | SET GET INCR SETNX |
| Hash | 哈希表+压缩列表 | 对象存储、用户信息、购物车 | HSET HGET HGETALL |
| List | 双向链表+压缩列表 | 消息队列、时间线、最新列表 | LPUSH RPOP LRANGE |
| Set | 哈希表+整数集合 | 去重、共同关注、随机抽奖 | SADD SINTER SPOP |
| ZSet | 跳跃表+哈希表 | 排行榜、优先级队列、延迟队列 | ZADD ZRANGE ZSCORE |
为什么说一个Redis能顶几个工具？举例说明：
- 排行榜需求：用ZSet，每次用户分数变化执行一次ZADD，查询排名直接ZREVRANGE，几十行代码搞定。换成MySQL，你得设计分数表、定期聚合、还要处理索引和缓存，成本不是一个量级。
- 去重需求：用Set的SADD去重，配合SISMEMBER判断是否存在，复杂度O(1)。布隆过滤器虽然更省内存，但会有误判率，不是所有场景都适用。
- 最新消息列表：用List的LPUSH + LTRIM，把列表长度控制在一定范围内，天然就是“只保留最近N条”的数据结构。
- 在线人数统计：用Set存储在线用户ID，登录SADD，退出SREM，统计SCARD，简单直接。
除了这五种基础类型，Redis还有Bitmap、HyperLogLog、Geo、Stream等扩展结构。Bitmap常用于签到、布隆过滤器场景，HyperLogLog可以用极小的内存统计海量UV，Geo直接支持附近的人查询，Stream是Redis 5.0之后引入的完善消息队列模型。这些结构都是Redis的优势所在——你不需要在系统里塞进七八种中间件，一个Redis能解决的问题，就不要让架构更复杂。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从高频场景看Redis特点怎么落地
光知道数据类型和底层原理还不够，真正有区分度的是“场景建模”能力。同一个Redis，在不同的业务里能玩出完全不同的花样。我挑几个非常典型并且高频的场景，说一下Redis的特点是怎么变成实际生产力的。
2.1 缓存场景：穿透、击穿、雪崩与分页优化
缓存是Redis最基础的用途，但“把数据放Redis里”只是第一步。真正考验功力的，是处理缓存穿透、缓存击穿、缓存雪崩这三件事。
- 缓存穿透：请求的数据在缓存和数据库里都不存在，导致每次请求都打到数据库。黑客如果恶意构造不存在的key，数据库压力会很大。规避方案有三种：对空值也做缓存（过期时间设短一点）、用布隆过滤器前置拦截、在接口层做参数校验。
- 缓存击穿：热点key在缓存过期的瞬间，大量请求同时打到数据库。解决思路是互斥锁（分布式锁）、逻辑过期、热点key永不过期+后台异步刷新。
- 缓存雪崩：大量key在同一时间段集中过期，或者Redis实例宕机，导致流量直接打到数据库。解决思路：过期时间加随机值打散，多级缓存，Redis高可用（哨兵/集群）。
这里要特别提一下从热搜词里高频出现的“分页查询慢怎么用Redis优化”。很多人以为分页查询优化就是用Redis缓存整张表，这是误区。合理的做法是先分析查询瓶颈在哪里。
如果是排序分页频繁且数据集相对稳定，可以预先把排序结果写入ZSet，用ZRANGE做分页，时间复杂度接近O(logN + M)，比数据库里ORDER BY LIMIT走文件排序要快得多。如果是WHERE条件过滤后的分页，可以用缓存保存“筛选条件对应的ID列表”，然后只回表查当前页所需的少量记录。我做过一个管理后台的列表页优化，原接口平均耗时320ms，优化后压到15ms以内，关键点不是缓存全量数据，而是用缓存保存过滤后的ID列表、再用MySQL只查当前页字段。
还有一种常见优化是缓存多级页面数据，比如列表第一页的返回结果整体序列化后存到String里，设置5-10秒过期。这种方案在C端首页很有效，因为前几页的访问热度远高于后面的页。
2.2 分布式锁：SETNX与Redisson的取舍
Redis实现分布式锁是高频话题。最早的做法是SETNX加过期时间：
bash复制SET lock_key unique_value NX EX 30
设置成功后，业务执行完再调用Lua脚本释放锁，并校验unique_value是否是自己当初设置的值，防止误删别人的锁。
为什么一定要用Lua脚本？因为释放锁的“判断value + DEL删除”是两步操作，如果不是原子执行，就可能出现A的锁被B删除的情况。用Lua脚本把两步合成一步，利用单线程模型保证原子性，这是回答分布式锁问题的关键点。
不过从生产实践来看，原生SETNX方案在复杂场景下并不够用。假设业务执行时间超过了锁的过期时间，锁自动释放了，另一个线程拿到了锁，这时第一个线程执行完再释放，就会误删别人的锁。这个坑虽然可以通过“续期”避免，但自己实现续期逻辑很容易出错。
所以生产上我更推荐直接用Redisson。Redisson提供了看门狗机制，默认情况下锁有效期是30秒，如果业务没执行完，看门狗每10秒自动续期一次，避免锁过期被误删。它还封装了可重入锁、公平锁、读写锁。注意，Redisson的看门狗不是万能的，如果Redis节点故障，或者业务线程被阻塞到连续期都发不出去，锁照样会失效。
至于Redis主从架构下的“红锁（RedLock）”问题，我个人的看法是：如果你们的业务对分布式锁的可靠性要求极高，比如涉及到资金操作，那可以考虑红锁；但同时要接受它的复杂度和性能损耗。绝大多数互联网业务，单节点Redis + Redisson已经够用，过度设计不一定是好事。
2.3 消息队列与异步任务：Stream和List的实战
Redis常被用来做轻量级消息队列。最朴素的方式是List的LPUSH + BRPOP，生产者LPUSH消息，消费者BRPOP阻塞读取。这个模型简单可靠，但有一个问题：不支持多消费者组，消息消费后立刻从List移除，没有ACK机制，消费者崩了消息就丢了。
Redis 5.0引入的Stream类型，本质上就是为了弥补List方案在消息队列场景的不足。Stream支持消费者组、ACK确认、pending消息恢复、消息ID排序等能力。它虽然不是专业消息队列（比如Kafka、RocketMQ），但胜在轻量、无需额外部署中间件。
热搜词里有个“redis消息队列 + 结果存储broker + backend 双”，我猜测它是某类异步任务框架里的存储设计：Redis既作为消息队列的broker，把待处理任务存起来，又作为backend存储执行结果。这种模式在分布式任务系统里确实常见，比如用Redis List存任务ID，用Hash存每个任务的状态和结果，消费者从List取任务，处理完成后把结果写进Hash并更新状态字段。这样设计的好处是：任务状态即查即得，不需要回源数据库，而且Redis的过期机制还能自动清理历史结果。
我在一个回调通知项目里用Redis做过简化版延迟队列。ZSet的score存“下次执行时间戳”，消费者定时器每隔几秒执行一次ZRANGEBYSCORE取出到期任务，处理成功就删除，失败则重新计算score并加入。这套方案处理了几十万条消息，没有出过大问题。需要注意的细节是：消费端要防止重复执行任务，最好在业务逻辑里做幂等处理；如果任务量很大，轮询间隔要调优，避免空转消耗CPU。
2.4 去重、计数、排行榜与向量检索：被低估的用法
很多团队只用Redis做缓存，这其实浪费了它的能力。Redis在去重、计数、排行榜、统计类场景里，经常能替代一部分数据库职责，让系统更轻。
- 计数器：INCR做点赞数、阅读数、库存扣减，配合EXPIRE可以生成时间窗口计数器，比如“过去5分钟的请求量”用于限流。
- 布隆过滤器：可以用BitMap自己实现，或者用Redis Stack提供的BF模块。适合做“已读/未读”判断中容忍部分误判的场景，节省大量内存。
- 排行榜：ZSet的分数排序能力非常强。比如游戏战力榜、热销榜、积分榜，只要写入分数，查询排名和TopN都是毫秒级别的。
- 在线状态与签到：BitMap按位存储，假设你有1亿用户，记录每天的签到状态只需要约12MB内存，压缩效果非常可观。用GETBIT判断某用户某天是否签到，用BITCOUNT统计签到人数。
- 附近的人：Geo类型可以计算经纬度距离、搜索附近的点，做LBS轻量场景非常合适。
- 向量检索：这是近期热度上升较快的方向。Redis Stack新增了向量集合（Vector Set），可以存储向量并做相似度检索。如果业务量不大、不想引入专门的向量数据库，Redis可以顶上去。
这些场景的共同特点是：数据和热点高度集中、规模可控、对性能要求高。Redis正好都满足。区别只在于你有没有把Redis当成一个“数据结构服务器”来思考，而不仅仅是一个“手机缓存”。
3. 把优势变成生产力的实操要点
理论讲得再多，落地还是要靠操作。这里我把Redis从安装到治理的过程过一遍，重点说一些文档里不常写、但实战中很影响体验的细节。
3.1 安装与启动：Linux、Windows、Docker三种方式
热搜词里“redis下载、redis安装、windows安装redis、docker安装redis主从”这些搜索热度非常高，说明大家第一步就容易被安装卡住。我分别说下三种常用方式的注意事项。
Linux环境是最推荐的。官方源码编译安装三步走：
bash复制wget https://download.redis.io/releases/redis-7.2.4.tar.gz
tar -xzf redis-7.2.4.tar.gz
cd redis-7.2.4
make
make install
编译前需要确认系统有gcc和make工具。装完之后，redis-server就在/usr/local/bin下。启动时一定要指定配置文件，否则Redis会使用默认配置，既没有持久化，也不允许后台运行。
bash复制redis-server /etc/redis/redis.conf
配置文件里最常改的几项：
conf复制daemonize yes # 后台运行
requirepass yourpass # 设置密码
maxmemory 2gb # 限制内存，防止OOM
maxmemory-policy allkeys-lru # 内存淘汰策略
appendonly yes # 开启AOF持久化
Windows环境比较特殊，官方其实不提供Windows版本，大家平时下的Windows版是微软或开源社区维护的。下载解压后直接运行redis-server.exe即可。需要注意：Windows版的Redis版本往往落后于Linux版，生产环境不建议用Windows跑Redis，开发调试可以凑合用。
Docker方式是我最推荐的。开发环境一条命令就能拉起：
bash复制docker run -d --name redis \
-p 6379:6379 \
-v /data/redis/conf/redis.conf:/etc/redis/redis.conf \
-v /data/redis/data:/data \
redis:7.2 redis-server /etc/redis/redis.conf
要搭主从也容易，起两个容器，在从节点配置文件里加一行“replicaof”即可。主从的好处是读写分离和数据冗余，普通项目搭一主一从加哨兵就够了。
提示：不管哪种方式，生产环境一定要设置密码，并且不要用默认端口6379暴露到公网。Redis的漏洞曾经导致很多服务器被入侵挖矿，安全配置不是可选操作。
3.2 可视化客户端怎么选：RDM、Another Redis Desktop Manager、Redis Insight
命令敲多了确实累，可视化工具能提高不少效率。热搜词里“redis desktop manager、another redis desktop manager、redis insight”都出现得很频繁，我三个都用过，说下感受。
- Redis Desktop Manager（RDM）：老牌工具，界面简洁，连接管理方便。早期版本有些功能收费，现在新版开源版已经很好用。适合日常查看key、执行简单命令。
- Another Redis Desktop Manager：国内开发者维护的免费工具，功能比RDM更丰富，支持SSH隧道、内存分析、慢日志查看，连接大量Redis实例时性能也不错。
- Redis Insight：Redis官方出品，界面现代化，集成了数据浏览、命令面板、性能监控、Redis Stack模块的可视化。如果要体验官方新特性，或者调试向量检索、JSON类型，建议用这个。
使用可视化工具时有个实用习惯：查看线上数据时不要随便执行KEYS操作，先在过滤框里用前缀精确匹配。很多工具的“获取全部key”功能在某些版本里会触发KEYS命令，遇到大key库直接阻塞实例，这个问题在3.3里细说。
3.3 缓存治理与内存节省技巧
“Redis缓存治理”是个很容易被忽视的话题。很多人把数据塞进Redis就完事了，等内存报警或者命中率下降，才开始头疼。缓存治理的核心目标有三个：提高命中率、控制内存用量、避免故障影响业务。
提高命中率的举措包括：
- 热点key统一缓存，不设过期时间，配合后台定时刷新。
- 冷热数据分离，Redis只保留热点，冷数据交给数据库。
- 过期时间设置为“基础时间+随机值”，避免同时失效引发雪崩。
- 上线前评估缓存粒度。比如用户信息按用户维度缓存，比整表缓存更灵活且内存占用更低。
控制内存用量的常用手段：
- 合理设置maxmemory和淘汰策略。业务缓存用allkeys-lru，按最近使用频率淘汰；业务数据不允许丢失的，用noeviction并做好监控。
- 尽量用小数据结构。Hash、ZSet在元素少时会使用压缩列表（ziplist）存储，内存占用远小于哈希表，存用户信息比多个String更省内存。
- 使用HyperLogLog替代Set做UV统计，1万条数据占用几十KB和几千KB的区别是巨大的。
- 大文本数据压缩后再存。如果缓存值是大JSON字符串，用zstd或lz4压缩后再写入，能省一半以上内存，代价是cpu消耗略有增加。
故障影响业务的应对措施：本地缓存+Redis双级缓存，Redis挂了还有本地缓存兜底；Redis不可用时做熔断和降级，不能让数据库直接被击穿。
3.4 主从、哨兵与集群：高可用怎么搭
单机Redis再快，也扛不住节点故障。生产环境至少要做到主从+哨兵。简单说下三种架构的适用场景：
- 主从复制：一主多从，主节点负责写，从节点负责读，数据异步同步。适合读写分离、数据备份场景。但主节点挂了，需要手动切换。
- 哨兵（Sentinel）：在主从基础上加一层哨兵进程，监控主节点状态，主节点故障时自动选举新的主节点，并通知客户端新的主节点地址。这是在“不换架构”的前提下最稳的可用性方案。
- Redis Cluster：内置分片和高可用能力，数据自动按slot分布到多个master节点，每个master带一个或多个slave。当数据量超过单机内存、或者写并发超高时，Cluster是更优选择。
从热搜词里我注意到“redis集群1如何将数据同步到集群2”，这其实是集群间数据迁移的问题。常见的做法有几种：
- 使用redis-shake等工具做跨集群同步、迁移。redis-shake支持全量+增量同步，是目前比较常用的方案。
- RDB文件和AOF文件导入。只适合停机迁移。
- 在应用层做双写，适合灰度迁移场景。
我只能说，跨集群同步没有银弹。如果两个集群版本不同、网络隔离，迁移过程很容易遇到编码或版本兼容问题。建议迁移前先在测试环境跑通redis-shake，并做好数据校验，不要直接在线上搞，否则回滚成本很高。
4. 面试考点与排障实录
Redis的优势和特点能讲多深，往往决定面试官对你的评价。这里我把高频面试题和一些排障经验整理出来，方便大家查漏补缺。
4.1 高频面试题怎么答
下面是我近期在团队面试里经常问的几个点，也是候选人反馈“被问到过”的问题。
Redis为什么快？ 回答要点：内存存储、单线程避免了线程切换和锁竞争、IO多路复用、核心命令O(1)复杂度。如果还能补充“高效的数据结构编码方式，比如跳表、压缩表”，会明显加分。
Redis是单线程的，为什么还能支持高并发？ 回答要点：命令执行是串行的，但IO处理在6.0后已经多线程化。Redis的瓶颈不是CPU而是网络和内存，单线程在IO密集场景下足够，而且规避了并发安全问题。
缓存穿透和缓存击穿的区别是什么？ 穿透是“查询的数据根本不存在”，击穿是“热点key过期瞬间大量请求砸过来”。很多候选人会混淆，面试官往往通过这个细节判断基础牢不牢。
Redis的持久化机制有哪些？ RDB是快照，AOF是追加日志。RDB适合备份恢复，AOF数据更安全但文件大。生产环境通常两者结合，同时开启AOF做主持久化，RDB做快速恢复。还要补充“混合持久化”是Redis 4.0之后引入的。
怎么实现分布式锁？ 说清楚SETNX + 过期时间 + Lua释放 + 唯一value的流程，再说Redisson的看门狗续期，最后提一下红锁适用的极端场景。能讲清楚这个层次就算合格。
Redis过期删除策略和内存淘汰策略有什么区别？ 过期删除关注的是“已过期key怎么清理”，策略有惰性删除和定期删除；内存淘汰关注的是“内存满了怎么办”，策略有noeviction、allkeys-lru、allkeys-lfu等。注意不要混为一谈。
还有一个知乎和博客里经常看到的问题：Redis 的 List 底层是链表，那用 List 做队列会不会很慢？答案是链表虽然有O(1)头尾操作，但查询中间元素是O(N)。列表元素多的时候，底层会从“压缩列表”转换为“链表”（7.2版本后是quicklist），实际上绝大部分操作都是头尾，性能完全可接受。
4.2 慢查询、keys阻塞与big key问题
聊到Redis排障，我最想提醒大家的就是别在生产环境用KEYS命令。这个命令会扫描全库的key，单线程执行，数据量一大直接卡住整个Redis实例。我见过一个真实事故：某团队在排查问题时执行了KEYS a*，结果Redis里有两千万个key，线上服务整整阻塞了几十秒。
替代方案：
- 使用SCAN命令。它是游标式遍历，每次返回少量key，不会阻塞实例。缺点是无法一次拿到全部，需要多次迭代。
- 自查key的分布用Redis Insight或者Another Redis Desktop Manager的内存分析功能。
- 如果真的需要频繁按前缀查询，建议在key设计阶段就规划好，把业务前缀一致的数据放到同一个Hash里，减少遍历开销。
big key问题也需要警惕。一个key里存了上百万个元素的Set，或者一个几MB的String，会导致复制延迟、持久化阻塞、删除卡顿。排查方法：
- 使用redis-cli --bigkeys命令扫描大key。
- 在工具里按内存排序查看。
处理方案：
- 字符串大key拆分，比如按业务维度拆成多个key。
- 集合类大key分批删除：用SSCAN + SREM逐步清理，不要直接DEL。
- 从根源上避免：设计阶段就要评估数据量，不要在Redis里存大对象。
慢查询的排查可以打开慢查询日志。在redis.conf里设置：
conf复制slowlog-log-slower-than 10000 # 记录超过10ms的命令
slowlog-max-len 128
然后通过SLOWLOG GET命令查看。慢日志能直接帮助你定位到是哪条命令拖慢了Redis，多数时候问题出在不当使用SORT、KEYS、或者大key的操作上。
4.3 Redis 7/8的新特性要点
想体现自己对Redis发展趋势的理解，可以关注几个新特性。
Redis 7.0最主要的更新是引入了AOF多部分文件机制，把AOF重写时的复制和更新拆开，有效减少了重写期间对主进程的阻塞。同时，Redis 7.0将原来有些“私有”的函数库改成了Function API，让脚本管理更规范。
Redis 7.2和Redis Stack则进一步拓宽了使用边界，支持JSON数据类型、时间序列、向量检索等模块。如果你把Redis当成一个“二等公民”中间件，这些新特性可能用不上；但如果做中小型项目，Redis Stack确实能减少技术栈的数量。
Redis 8.0目前的信息集中在更细粒度的复制机制、更好的内存效率、以及集群支持方面的提升。具体细节还在演进中，我们可以保持关注，但不必因为追新就盲目升级，生产环境求稳更重要。
我个人对“Redis新特性”的态度是：不用急着追，等版本稳定后再上。中间件最怕的是踩到不兼容的坑，升级前一定要做全量回归测试。
5. 最后说点个人经验
Redis这套东西我用了差不多八年，从最早的2.8版本一路用到7.x，中间踩过不少坑，也总结了几个比较实用的经验。
第一个经验是关于“Redis到底该存什么”的，我现在的原则是“缓存只放热数据，状态数据要设计过期策略，业务数据绝不依赖Redis持久化”。很多人一开始容易把Redis当成万能数据库，什么数据都往里面塞，结果内存溢出了、数据丢了才发现问题。
第二个经验是，不管业务规模大小，都不要裸奔跑Redis。哪怕只有一个节点，也要至少有RDB持久化、maxmemory限制、密码认证、慢查询日志这四件套。等出事故再补，代价会让你很难受。
第三个经验是学Redis不要只会CRUD。花点时间把它的数据结构特性、持久化机制、集群模式、内存淘汰策略搞懂，你会发现它在系统里能扮演的角色远比“缓存”两个字要丰富得多。遇到并发、分页、排行榜、分布式一致性这些问题，你会比其他人多一套解决方案。
我在实际项目里最省心的一个场景是：用Redis同时撑起了业务缓存、接口幂等、分布式锁、排行榜、轻量级消息队列这五件事，整个中间件只多部署了一套Redis，没有引入任何其他重量级组件。这就是Redis最大的魅力，也是我为什么一直推荐身边的朋友把它学透。