Redis从入门到实践：五大类型、持久化与生产环境避坑指南

Redis缓存持久化

于 2026-10-02 08:17:39 修改

·本内容遵循CC 4.0 BY-SA版权协议

Redis这个单词，后端开发应该都听过；但真正把它用明白的人，说实话不多。它全称是Remote Dictionary Server，翻译过来就是远程字典服务器，本质上是一个基于内存的key-value存储系统，现在几乎每个有点规模的互联网项目里都少不了它。这篇文章我打算用一篇文章的体量，带你把Redis从安装、基本命令、数据类型，到持久化、主从复制和生产环境的常见坑都过一遍。适合刚接触Redis的在校学生、准备面试的应届生，以及工作中刚被安排维护Redis的初级开发。

我会尽量少讲空泛的概念，多讲“这东西到底怎么用、为什么这么用”。毕竟Redis这门手艺，光看文档是学不会的，你得亲手敲一遍命令、亲手踩一遍坑，才知道网上那些教程里没写的东西有多值钱。

1. Redis是什么？先搞清楚它到底解决了什么问题

1.1 从“缓存”到“数据结构服务器”的定位

很多人一说到Redis就脱口而出“缓存”，这个说法没错，但太片面了。Redis的中文名叫“远程字典服务器”，它最底层的模型就是一个巨大的字典（或者说Map），你可以往里面存key和value，然后通过这个key在极短时间内取回value。这个模型和Java里的HashMap、Python里的dict非常像，只不过它跑在独立的进程里，可以被多个应用共享，所以叫“远程字典”。

但Redis真正的价值，在于它不只会存字符串，还提供了一套丰富的数据结构。你可以把value存成Hash、List、Set、ZSet（有序集合），然后在服务端直接对这些结构做操作，比如往List里推一条消息、给ZSet里的成员按分数排序、对Set做交集并集计算。这意味着你要实现“排行榜”“共同好友”“消息队列”这类功能，不必把数据拉回业务代码里慢慢算，直接在Redis里就用一条命令搞定了。

这也是它和Memcached最大的区别。Memcached基本只能存字符串，缓存过期就完事；Redis则是“带数据结构的缓存服务器”，能做的事情多得多。入门时先把“缓存”这两个字忘掉，记住它是“基于内存的数据结构服务器”，你的视野会开阔很多。

1.2 为什么它这么快：单线程、IO多路复用、内存为什么是银弹

新手最容易问的一句话就是：Redis为什么那么快？其实核心原因有三个，而且这三个原因都特别好理解。

首先，数据存在内存里。内存本身的读写速度就是纳秒级别的，比磁盘快几个数量级。这个是最关键的原因，没有之一。很多人搞混淆，以为Redis快是因为什么高深的算法，其实最本质的原因就是它压根不碰磁盘，所有读写都在内存里完成，只在需要持久化的时候才异步落盘。

其次，Redis是单线程模型。注意，这个“单线程”指的是处理命令的线程只有一个，所有命令在它内部都是排队执行的。这样做的好处是：不用加锁、没有上下文切换开销、不会出现并发竞争问题。坏处显然也有，就是单个命令不能太重，比如keys *这种全量扫描在生产环境就很危险，因为一个慢命令会阻塞后面所有命令。

最后，它用了IO多路复用机制。通俗点说，当Redis等待网络数据时，不会傻等某一个连接的数据，而是让内核同时盯着很多个连接，哪个连接有数据来了就处理哪个。这个机制让单线程也能支撑很高的并发连接数。

所以你可以这样理解Redis的架构：一个不需要睡觉的收银员，排在超市门口，顾客从各个入口涌进来，哪个到了柜台就为哪个结账。只要每个顾客结账都很快，这个超市就能同时服务很多人。

1.3 你到底该用它做什么、不该做什么

Redis能做的事情很多，但不是所有事情都适合用它。我见过不少团队把Redis当成万能数据库，什么数据都往里塞，最后内存吃紧、数据错乱，还得回头收拾烂摊子。

适合用Redis的场景大概有这几类：缓存热点数据，比如用户信息、商品详情；做分布式锁，保证多台机器上同一时间只有一个进程执行某段逻辑；实现排行榜和计数器的实时统计；做简单的消息队列；存验证码、会话Session这类短时效数据。这些场景的共同点是：读写频繁、对延迟极度敏感、数据量不大、可以接受一定的丢失风险。

不适合用Redis的场景也很多。比如复杂的关系型查询，涉及多表关联、聚合统计，这根本不是Redis的强项；再比如强一致性的金融交易数据，虽然Redis也支持事务和持久化，但它的设计目标从来不是做银行系统的主存储，硬要用它存核心账务，出问题只是迟早的事。入门阶段你得先记住一个判断标准：把Redis当“高速公路边的服务区”，别把整座城市都建在高速服务区里。

2. 安装与上手：三种环境下绕不开的坑

2.1 Windows下怎么装Redis才不折腾

先说一个很多新手都会困惑的事：Redis官网为什么不提供Windows版本？原因是Redis依赖Linux的一些系统特性来做持久化和网络处理，官方一直只维护Linux和macOS版本。但你要在Windows上学习，方法也不少。

我实测下来，最省心的方式是去GitHub找一个叫tporadowski的维护版本。这个项目把Redis的Windows移植版打包成了zip和msi安装包，下载解压之后目录里有个redis-server.exe，双击就能启动，默认监听6379端口。还有个redis-cli.exe，是命令行客户端，装完可以用它来测试连接。

还有一种方式是开箱即用的Docker Desktop方案。如果你机器上装了Docker，直接跑一条命令：

BASH

docker run -d --name redis -p 6379:6379 redis:7.2

这条命令会从Docker Hub拉取官方镜像（注意，这里说的镜像是Docker镜像，是官方封装好的运行环境），然后以守护进程方式启动Redis。这个方式最大的好处是和Linux环境完全一致，不会遇到Windows移植版那些奇怪的小毛病。当然，前提是你得先装好Docker Desktop，这个对Windows 10/11用户来说不算难。

我个人不建议新手绕过这些方式，非要去啃源码在Windows上自己编译，那样做纯属浪费时间。学习阶段，能跑起来、能敲命令就行，后面线上环境谁还让你用Windows呢。

2.2 Linux服务器上最稳妥的安装方式与配置

生产环境或者云服务器上，最常见的安装方式是apt或yum直接装，也可以去官网redis.io下载源码包编译。直接装包管理器的版本最省事：

BASH

# Ubuntu / Debian

sudo apt update

sudo apt install redis-server

# CentOS / RHEL

sudo yum install redis

装完之后，服务默认是启动的。但这里有几个配置必须自己动手改，改完才算能上线。用vim /etc/redis/redis.conf打开配置文件，重点看这几项：

bind 127.0.0.1 -::1：默认只允许本机访问。如果想让局域网内其他机器访问，需要改成服务器的内网IP，但千万别改成0.0.0.0后再裸奔，会被人扫到爆破。
protected-mode yes：保护模式。默认开启，如果没设置密码又监听了公网，Redis只允许本机访问，外部连接会被拒绝。
requirepass yourpassword：设置访问密码。这是最重要的一条，凡是暴露到网络上的Redis，没有密码等于把家钥匙挂在门口。
daemonize yes：让Redis在后台以守护进程方式运行。如果保持no，你关掉终端Redis就跟着退了。

改完配置后重启服务，再用带密码的方式连一下：

BASH

sudo systemctl restart redis

redis-cli -a yourpassword ping

看到返回PONG，说明基本环境就通了。

2.3 Docker运行Redis与docker-compose生产部署参考

现在很多公司的Redis都是跑在Docker或Kubernetes里的，作为一个入门者，学会用docker-compose部署Redis绝对是加分项。这里给出一份可以用于生产环境的参考配置，别光复制，逐行看懂它做了什么：

YAML

version: "3.8"

services:

redis:

image: redis:7.2-alpine

container_name: redis

restart: always

ports:

- "6379:6379"

command: >

redis-server

--appendonly yes

--requirepass yourpassword

--maxmemory 512mb

--maxmemory-policy allkeys-lru

volumes:

- /data/redis:/data

这份配置里我开了AOF持久化（appendonly yes），设置了密码和内存上限，并挂载了数据目录。关键是volumes这一行，把容器里的/data目录映射到宿主机，否则容器一删数据全没了。restart: always保证宿主机重启后容器跟着自动起来，这个在生产环境非常重要。

如果要用Docker Compose搭建一主一从也很简单，再加一个从节点服务，配置上加上replicaof参数告诉它谁是主库就行。后面第4节我会给一个完整的compose示例。

2.4 客户端与管理工具：RDM、Another Redis Desktop Manager、Redis Insight

装好Redis之后，你不可能永远只用命令行，尤其当你存了几百个key时，一个可视化工具能让你直观地看到数据结构长什么样。

市面上常见的可视化客户端大概有三类：老牌的Redis Desktop Manager（简称RDM）、开源的Another Redis Desktop Manager，以及官方出的Redis Insight。RDM早期版本还算好用，但后来收费了；Another Redis Desktop Manager是开源免费的，界面类似RDM，Windows和macOS都能跑，下载也很方便。Redis Insight是官方亲儿子，功能比较全，还内置了内存分析、慢日志查询等功能，如果你是新手，我建议直接用Redis Insight，减少踩坑。

连接时填三个信息就行：主机地址（localhost或服务器IP）、端口（默认6379）、密码（如果配置了requirepass）。连不上时，90%的原因要么是bind限制，要么是防火墙没放通端口，要么是密码填错，按这个顺序排查基本都能解决。

3. 五种数据类型：命令、适用场景和序列化那些事

3.1 String：最基础也最常用

String是Redis里最基础的数据类型，一个key对应一个value，value最大能存512MB。它的命令看着简单，但实际场景非常广。

最常用的几个命令：

BASH

SET user:1 "张三"

GET user:1

INCR page:view

EXPIRE user:1 3600

SET和GET不用解释了，存和取。INCR是做计数器的神器，比如文章阅读量、点赞数，一条命令就能自增，而且它是原子的，并发场景下不会加错。EXPIRE是给key设置过期时间，几小时后自动删除，非常适合验证码、临时Token这类场景。

String还有一个特别经典的用法：分布式锁。一条命令搞定：

BASH

SET lock:order:1 1 NX PX 30000

NX表示只在key不存在时才写入，PX 30000表示锁的自动过期时间是3万毫秒。这样多个服务同时抢这把锁时，只有一个能成功写入，谁写入成功谁就拿到了锁。后面第4节我会再展开说这个。

3.2 Hash：字段级操作比JSON整体覆盖省心

Hash类型可以理解成一个嵌套的字典，一个key下面可以存很多个field-value对。最典型的场景是存用户信息、商品信息这类对象数据。

BASH

HSET user:1 name "张三" age 25 city "北京"

HGET user:1 name

HGETALL user:1

我特别想强调Hash的一个优点：当你只需要修改对象里的某一个字段时，用HSET只更新那一个字段，不需要把整个对象读取出来再整体覆盖写回去。这在缓存用户资料时特别有用，避免并发下“读-改-写”覆盖丢失的问题。

另外一个容易被忽略的场景是用Hash存配置项。比如把某个业务开关、某个策略参数放在一个Hash里，随时用HGET读取，更新时HSET单项设置，比存一个大JSON字符串灵活得多。

3.3 List：队列模型与缓存分页

List类型在Redis里是一个双向链表，可以从头部或者尾部推入和弹出元素。它最常见的两个用途是：实现简单的消息队列，和实现类似数据库分页的列表缓存。

BASH

LPUSH task:queue task-1

RPOP task:queue

LRANGE articles 0 9

当业务代码里一个进程LPUSH生产任务，另一个进程RPOP消费任务，这就构成了一个最原始但可用的消息队列。Redis还提供了阻塞版本的BRPOP，如果队列为空，它会一直等待直到有新元素进队，这比轮询更高效。

用LRANGE做分页也非常直观，比如LRANGE articles 0 9取第一页10条，LRANGE articles 10 19取第二页。这里要注意，LRANGE的时间复杂度是O(N)，N是取出的元素个数，所以用它做分页时列表长度别太夸张，几万条以内问题不大，要是几十万上百万，还是老老实实用数据库分页吧。

3.4 Set与ZSet：去重、交集并集、排行榜

Set是无序的字符串集合，元素不能重复，它最强大的地方在于支持集合运算：交集、并集、差集。

BASH

SADD user:1:tags "java" "redis" "mysql"

SADD user:2:tags "java" "python"

SINTER user:1:tags user:2:tags

SINTER取两个集合的交集，直接得到两个用户的共同标签，这在实现“共同好友”“相似推荐”这类功能时是利器，一行命令PK掉一大段Java代码。

ZSet在Set的基础上给每个元素加了一个分数（score），Redis自动按分数从小到大排序。这个特性让它成为实现排行榜的首选：

BASH

ZADD ranking 100 "player_a"

ZADD ranking 95 "player_b"

ZRANGE ranking 0 -1

游戏排行榜、积分榜、热门文章榜，都可以用ZSet搞定。更新分数用ZINCRBY，查询排名用ZREVRANK，一条命令一个功能，而且性能非常稳定。

3.5 序列化问题的本质：为什么客户端里看到的key是乱码

很多新手第一次用Java或Go的Redis客户端时，打开可视化工具一看，key不是自己存的字符串，而是一堆\xAC\xED\x00\x05t...之类的二进制乱码，瞬间就懵了。这个问题在热词里叫“redis序列化”，根源在于客户端默认用了JDK自带的序列化方式，把对象序列化成了二进制字节。

举个例子，你用Spring Boot的RedisTemplate存了一个字符串，默认的JdkSerializationRedisSerializer会在key和value前面加一堆类型头信息，Redis里存的就是这个样子。解决办法有两种：

如果只存字符串，用StringRedisTemplate，它的key和value都用String序列化器，完全不乱码。
如果需要存对象，在RedisTemplate上显式设置JSON序列化器，比如GenericJackson2JsonRedisSerializer，存进去的是可读的JSON字符串。

这个坑几乎每个用Spring Boot的开发者都会踩一次，提前知道能省不少排查时间。核心原则是：存进去是什么格式，取出来就要用对应的反序列化器去解析，别把字符串存进去，用对象序列化器去读。

4. 持久化、高可用与生产必知项

4.1 RDB与AOF：先选对策略再谈数据安全

Redis虽然基于内存，但绝不能把数据全放在内存里不管，一旦进程崩溃或者机器宕机，内存数据就全没了。所以Redis提供了两种持久化方式：RDB快照和AOF日志。

RDB（Redis Database）的思路是定期把内存里的全量数据生成一个二进制快照文件，默认叫dump.rdb。你可以配置save 900 1表示900秒内至少有1个key变化就触发一次快照，也可以手动执行BGSAVE。它的优点是文件紧凑、恢复速度快，缺点是两次快照之间的数据会丢失，而且生成快照时如果数据量大，还是有一点性能开销。

AOF（Append Only File）的思路是把每一条写命令追加到一个日志文件里，重启时按日志逐步执行来恢复数据。AOF有三种刷盘策略：always每条命令都写磁盘，最安全但最慢；everysec每秒刷一次，损失的窗口最多1秒；no交给操作系统决定，安全性最差。实际生产环境中everysec是性能和安全的平衡点，也是官方默认推荐。

这两者怎么选？如果数据丢了能接受、追求恢复速度，用RDB就行；如果对数据安全要求高，建议AOF开启，甚至可以把两种都打开，Redis重启时会优先用AOF恢复数据。我的建议是：开发环境开RDB就够，生产环境至少开AOF，并且设置好appendfsync everysec。

另外，Redis 4.0以后引入的混合持久化模式也值得了解。它把RDB快照和AOF增量日志合在一起，重启恢复时先加载RDB再重放增量命令，兼顾了恢复速度和数据完整性，配置项是aof-use-rdb-preamble yes。

对比项	RDB	AOF
文件格式	二进制快照	文本日志
恢复速度	快	慢
数据丢失窗口	取决于快照频率	取决于刷盘策略
文件大小	紧凑	可能较大，支持重写
适用场景	缓存、可容忍丢失	对数据安全要求较高的场景

4.2 主从复制与Docker Compose部署一套可用的主从环境

单台Redis有单点风险：它挂了，所有依赖它的服务都会雪崩。解决这个问题的第一步是搭建主从复制，一个主库，一个或多个从库，主库负责写，从库同步数据并负责读。

从库的同步原理不复杂：从库启动后向主库发送同步请求，主库生成一份RDB快照发给从库，后续的新写命令再持续推给从库执行。所以主从之间天然是异步复制，从库的数据比主库落后一点点，这在高并发下是可以接受的。

用Docker Compose搭建一主一从是最快的验证方式。我直接给出一个可用的配置：

YAML

version: "3.8"

services:

redis-master:

image: redis:7.2-alpine

container_name: redis-master

restart: always

ports:

- "6379:6379"

command: redis-server --requirepass masterpass --appendonly yes

volumes:

- ./master-data:/data

redis-slave:

image: redis:7.2-alpine

container_name: redis-slave

restart: always

ports:

- "6380:6379"

command: redis-server --replicaof redis-master 6379 --masterauth masterpass --requirepass slavepass --appendonly yes

volumes:

- ./slave-data:/data

depends_on:

- redis-master

关键点在从节点的--replicaof redis-master 6379，意思是它要复制主库；--masterauth masterpass是连接主库时用的密码。启动后，在主库写入数据，在从库执行GET能查到，说明主从已经通了。

主从只能解决读扩展和部分高可用问题，主库宕机后不能自动切换，这时需要引入哨兵（Sentinel）或者直接上集群模式，那是后话了。入门阶段先把主从原理和配置搞明白，后面理解哨兵和Cluster会轻松很多。

4.3 缓存治理三板斧：穿透、击穿、雪崩，以及内存淘汰策略

凡是拿Redis做缓存的团队，迟早会面临三个经典问题：缓存穿透、缓存击穿、缓存雪崩。这三个词很容易搞混，我用大白话讲清楚。

缓存穿透，是指查询一个根本不存在的数据，缓存里没有，数据库里也没有，每次请求都直接打到数据库。破解思路有两个：一是把查询空结果也缓存起来，只是过期时间短一点；二是用布隆过滤器，在请求进入前先判断这个key大概率存不存在，不存在就直接返回。

缓存击穿，是指某个热点key突然过期，大量并发请求同时打到数据库。常见的解法是加互斥锁，让只有一个请求去数据库加载数据并重建缓存，其他请求等待缓存生效后用缓存数据。

缓存雪崩，是指大量key在同一时间段集中过期，或者Redis宕机，导致大量请求全部落到数据库。解法包括：给过期时间加上随机值，让它们错开；设置多级缓存，Redis挂了还有本地缓存顶着。

和缓存治理紧密相关的还有内存淘汰策略。Redis内存不是无限的，你需要通过maxmemory设置内存上限，然后通过maxmemory-policy决定满了以后谁该被淘汰。

淘汰策略	说明	适用场景
noeviction	不淘汰，内存满时写入报错	不能丢数据的场景
allkeys-lru	从所有key中淘汰最近最少使用	常规缓存场景
volatile-lru	只从设置了过期时间的key中淘汰LRU	混合缓存与固定数据
allkeys-random	随机淘汰任意key	热点不明显
volatile-ttl	淘汰即将过期的key	过期时间有梯度的场景

生产环境常用allkeys-lru，配合maxmemory设置一个合理阈值，避免Redis内存被写爆导致OOM崩溃。

4.4 事务、Lua脚本与分布式锁：知道原理才能谈深入

Redis的事务和MySQL的事务不是一回事，你要先有这个心理预期。Redis事务用MULTI开启，EXEC执行，中间的命令会排队，最后一次性执行。它保证这串命令在执行过程中不会被其他命令穿插，但不支持回滚。

BASH

MULTI

SET user:1 "张三"

INCR user:1:age

EXEC

这种事务适合一些简单的“多条命令原子执行”的场景。但如果事务里某条命令执行失败了，前面的命令已经生效，Redis不会撤销，这点和数据库事务完全不同。

更强大的方式是Lua脚本。Redis支持在服务端执行一段Lua脚本，脚本里所有Redis操作都是原子的，而且逻辑可以由你控制。很多复杂的分布式锁、限流器都是用Lua脚本实现的，因为脚本的原子性正好解决了“判断-执行”两步操作之间被并发穿插的问题。

回到分布式锁，刚才提到可以用SET key value NX PX 30000实现，但完整的、健壮的分布式锁远不止一条命令那么简单。你还得考虑锁的续期、持有者标识（防止误删别人的锁）、解锁时的原子性等问题。这些在Redisson这类库里有现成的实现，真正用到时直接借助成熟方案，不建议自己从头写一套分布式锁，踩坑成本太高。

5. 常见问题排查与避坑实录：连接失败、乱码和慢命令

5.1 连不上Redis怎么办

连接不上Redis应该是最常见的问题了。我每次排查都按下面的顺序过一遍：

先看服务是否真的在运行。用redis-cli ping本机测一下，如果返回PONG说明服务正常，问题出在网络层面。本机都连不上，那基本是配置或进程的问题，去检查日志，确认端口没被占用、daemonize配置正确。

再看bind配置。Redis默认只绑定本机，如果客户端在另一台机器，必须把bind改成服务器网卡IP，或者使用0.0.0.0配合防火墙限制，但绝对不能在无密码的情况下监听公网。

然后检查防火墙。云服务器最常见的问题是安全组没放行6379端口。你可以在本地执行telnet 服务器IP 6379，如果连不上，先去安全组规则里把这个端口打开。这里特别提醒，安全组放行时来源范围尽量别写0.0.0.0/0，除非你确定密码足够强。

最后检查密码认证。如果设置了requirepass，客户端连接时必须带密码，命令行里用-a参数，或者客户端工具里填写密码。忘记密码的话，可以直接在运行中的Redis里执行CONFIG SET requirepass 新密码，但重启后会丢，最好再改配置文件。

5.2 key全是乱码、启动不了服务、内存不足

关于乱码，我前面已经说了，本质是客户端序列化方式的问题。这里再补一个常见场景：你用StringRedisTemplate存进去的key是user:1，但用Redis Desktop Manager看的时候发现前面带着一串二进制头，这是因为你用的连接工具默认按某种编码解析，而key本身被序列化过。解决方法还是统一序列化器，或者直接用StringRedisTemplate。

启动不了服务，这个问题在Windows上特别常见，十有八九是端口被占用。运行netstat -ano | findstr 6379看是哪个进程占了端口，找到PID后去任务管理器确认是不是Redis已经在跑，或者是其他程序占了。还有可能是配置文件里语法写错了，比如密码里有特殊字符没加引号，Redis启动时会直接报错退出，这时候打开日志文件看最后几行，通常能直接定位。

内存不足，就是Redis报OOM command not allowed when used memory。这是maxmemory设得太低，或者没设淘汰策略导致内存满了后不接受新写入。排查时用INFO memory看当前使用了多少内存，再用INFO stats看一眼淘汰了多少key，根据实际情况决定是加内存、优化过期时间还是调整淘汰策略。千万别遇到OOM就重启，重启后数据丢了问题还在。

5.3 线上Redis变慢、卡顿的初步排查

线上Redis变慢，很多初级开发第一反应是加机器，其实多数时候是命令没用好。

先看有没有慢命令。Redis提供了慢日志功能，默认执行时间超过10毫秒的命令会被记录下来，你可以在客户端里执行：

BASH

SLOWLOG GET 10

这条命令会返回最近10条慢命令，包括执行时间、参数等信息。如果发现KEYS、SMEMBERS、HGETALL这类全量操作频繁出现，说明业务代码里有人在用O(N)级别的命令处理大集合，这就是拖慢Redis的主要元凶。解决办法是把KEYS换成SCAN，把全量HGETALL换成按字段获取。

再看是不是有bigkey。所谓bigkey，就是一个key对应的value特别大，比如一个List里有几十万条数据。Redis处理这种大key时，网络传输和序列化都会很慢，还会阻塞其他命令。定位bigkey可以用redis-cli --bigkeys这个自带的扫描命令，它会统计出每个数据类型里最大的key是哪个。找到之后，要么拆分成多个小key，要么把数据挪到别的地方存。

看内存碎片率也有必要。执行INFO memory，如果mem_fragmentation_ratio长期大于1.5，说明内存碎片严重，可以在业务低峰期执行MEMORY PURGE整理碎片，不过这个命令可能会造成短暂的阻塞，要谨慎。

6. 一点学习路线与个人心得

最后聊点实在的。我在带新人的时候经常发现，很多人学Redis喜欢把命令背得滚瓜烂熟，但一到真实项目里就不知道怎么用。我的建议是，学命令的时候必须同步想一个问题：这条命令在什么业务场景下能用上？比如学了INCR，就顺手写一个阅读量计数的Demo；学了ZADD，就顺手做一个模拟排行榜，而不是等面试前几天才来突击。

实操方面，我强烈建议你在动手阶段就把Docker Compose玩熟。我见过太多人只在本地装了个Redis，上班后才发现公司里全是容器化部署，连端口映射都不认识。早一点学会用Docker跑Redis，后面适应生产环境会顺滑很多。

解决问题的思路比知识点本身更重要。遇到问题不要急着百度，先自己判断一下：是连接层、数据层还是命令本身的问题？是配置问题还是客户端问题？把排查路径走一遍，通常比自己盲猜效率高得多。

这篇文章写的都是入门必备的骨架，Redis还有很多东西没展开，比如集群、管道、Stream消息队列、Lua脚本实战等。把这些基础吃透之后再去啃那些，你会轻松很多。如果哪块你实际操作时碰到了意外问题，带着日志和数据规模来聊，比空对空讨论一千遍都有用。