企业官网建设流程全解析

1. 为什么新手都该从 Ubuntu + Redis 开始

先说结论：如果你刚刚开始接触 Linux 服务器，想学一个“装完就能立刻用、用了就能出效果、踩坑也容易搜到答案”的服务，Redis 绝对是最合适的练手对象之一。配合 Ubuntu 这个对新手最友好的发行版，整个安装和使用过程基本不会遇到编译地狱、依赖爆炸之类的劝退问题。

Redis 本质上是一个基于内存的键值数据库，最擅长干的事情就是“快”。它能把数据直接存在内存里，读写速度可以达到每秒十万次以上。平时我们说的缓存、排行榜、分布式锁、消息队列，背后大概率都有 Redis 的身影。很多新手第一次接触 Redis 是通过各种框架的缓存功能，比如 Python 的 Django、Java 的 Spring Boot，明明调用了 cache 方法，却完全不知道背后是什么东西在做存储。这篇指南就是把这些“黑盒”打开，让你在 Ubuntu 上亲手把 Redis 装起来、跑起来、用起来。

这套指南默认你用的是 Ubuntu 22.04 或 24.04 LTS，这两代系统是目前最主流的服务器和桌面版本，命令几乎完全通用。不管你是刚装好 Ubuntu 系统的纯新手，还是已经会敲一些 Linux 命令但没碰过 Redis 的进阶用户，都可以直接照着做。内容分成安装、配置、使用、排错四个部分，每一部分我都会给出一线实操时会真正用到的东西，而不是简单丢几条命令就完事。

2. 安装之前必须想清楚的事：版本、方式和适用场景

2.1 Redis 到底解决什么问题？先搞懂你为什么要装它

很多教程一上来就让你 apt-get install，装完 redis-cli ping 一下看到 PONG 就收工。但真正踩过坑的人都明白，安装只是最简单的一步，理解 Redis 在你项目里承担什么角色才是关键。

Redis 最常见的角色是“缓存层”。比如你的网站读数据库要 50 毫秒，但读 Redis 缓存只花 1 毫秒，省下来的这 49 毫秒在高并发场景下就是天壤之别。Redis 的第二个高频角色是“消息中间件”。它提供列表和发布订阅功能，可以让多个服务之间解耦通信，比如订单系统往 Redis 里塞一条消息，短信服务消费这条消息去发通知。第三种常见用法是“计数器”，比如文章浏览量、商品库存扣减，Redis 的原子性自增操作保证多台服务器同时操作也不会算错。第四种是分布式锁，多个服务抢同一资源时，用 Redis 的 SETNX 命令实现互斥。

搞清楚你要拿它做什么，才能决定后续怎么配置。只是本地开发环境临时用一下缓存，那默认配置就够；如果是生产环境做持久化存储，就得花心思研究 RDB、AOF、持久化策略这些东西。安装前这个决策非常重要，后面所有的配置选项都是围绕它展开的。

2.2 三个安装方式横向对比：apt、源码编译、Docker

在 Ubuntu 上装 Redis 最常见的方式有三种，新手最容易困惑的就是“我到底用哪个”。

第一种是 apt 直接安装。Ubuntu 官方软件源里带 redis-server 包，一条命令搞定，系统自动帮你处理依赖、注册 systemd 服务、配好开机自启。它的唯一缺点是版本可能不是最新的——Ubuntu 22.04 默认源里是 Redis 6.0.16，24.04 是 7.0.15，好在 6.x 和 7.x 的功能对绝大多数场景来说已经非常充裕，不会有“版本太老导致项目跑不起来”的尴尬。

第二种是源码编译安装。你去 redis.io 下载源码包，然后 make && make install。这种方式能拿到最新版本，还可以在编译时定制参数，适合有特殊追求或者被 apt 版本限制卡住的人。代价是要安装编译工具链，编译过程大概需要几分钟，对新手来说多点风险，但也不是什么难事。

第三种是 Docker 容器安装。docker run redis 一行命令就能起一个 Redis 实例，环境干净，版本随便选，删了重来不心疼。缺点是数据卷、端口映射、网络模式这些概念对新人是额外负担，而且天然多了一层容器转换，性能稍有损耗。

我给你的建议是：纯新手走 apt，这是阻力最小的一条路；已经有点经验的选源码编译，能体会到更多的可控感；日常开发机上想随便折腾的实验环境，用 Docker 反而最省事。下面的正文三种方式都会讲，你想选哪条就看当前阶段的需求。

2.3 初装环境和依赖准备：防止第一步就卡壳

安装前先把基础环境准备好，能帮你避免很多“装到一半报错”的尴尬局面。首先确保系统软件源是最新的，执行 apt update 刷新索引。这一步很多新手会跳过，结果一装就报依赖找不到，其实多半就是源索引过期了。

然后检查系统里是否已经有残留的 Redis 或者端口被占用。执行ss -tlnp | grep 6379，如果看到有进程监听 6379 端口，说明之前装过 Redis，继续操作前要先停掉旧服务。另外建议确认一下防火墙状态，Ubuntu 默认没有启用 ufw 是放行所有端口的，但如果你自己开过防火墙，就得记得放行 6379。很多新手装了 Redis 发现局域网其他机器连不上，排查到最后发现不是 Redis 的问题，而是防火墙把端口挡住了。

如果是走源码编译路线，还要先装编译工具链，apt install build-essential tcl一条命令就能搞定。build-essential 包含 gcc、g++、make 这些核心编译工具，tcl 是 Redis 跑测试脚本用的依赖，没有它 make test 会报错。不要觉得这一步多余，后面编译时如果缺东西再回来装反而更折腾。

3. 三种安装方式的完整实操记录

3.1 最简单的方式：apt 安装 Redis 并验证服务状态

我先把最推荐的 apt 安装完整走一遍。打开终端，执行：

sudo apt update sudo apt install redis-server -y

装完以后 Redis 服务会自动启动，并且注册为 systemd 服务。你可以用systemctl status redis-server查看它的运行状态，看到 active (running) 就说明服务已经起来了。再执行redis-cli ping，如果返回 PONG，说明 Redis 已经在正常工作了。

这里有一个细节特别值得注意：Ubuntu 的 redis-server 包安装完成后，默认配置里daemonize 参数是 no，意味着 Redis 由 systemd 以前台进程的方式托管，这完全正常。如果哪天你手动跑redis-server命令启动了一个前台进程，这个进程和服务是不同的，操作时要分清楚你改的是哪个实例。

默认配置下还有另外一个关键点：Redis 只监听127.0.0.1，也就是只有本机能连接。这个设定在开发环境里是安全的，但如果你的项目需要其他机器访问这台 Redis，就必须修改 bind 配置。具体怎么改，我在后面配置章节详细说。

apt 方式安装的优点就是省心，升级也方便，sudo apt upgrade redis-server就能完成版本升级。系统源的版本可能比不上官网最新版，但对于常规用法完全够用，等哪天你真的需要某个新特性再换源码编译也不迟。

3.2 进阶选择：源码编译安装最新版 Redis

如果你确实需要最新版本，或者想体验编译安装完整流程，源码编译是更好的选择。先去官网确认当前最新版本号，然后按步骤执行：

# 安装编译依赖 sudo apt install build-essential tcl -y # 下载源码包，以 7.4.x 为例 wget https://download.redis.io/releases/redis-7.4.1.tar.gz tar xzf redis-7.4.1.tar.gz cd redis-7.4.1 # 编译并测试 make make test # 安装到 /usr/local/bin sudo make install

整个过程里最容易卡住的就是 make test 这步。它会把 Redis 自己写的测试用例完整跑一遍，正常情况下需要几分钟。如果测试中途报错，先确认 tcl 是否装好，再检查系统时间和时区设置是否正确——这两步出问题的概率最大。

编译安装完成后，Redis 的可执行文件在/usr/local/bin下，但此时还没有自动注册成 systemd 服务，也没用默认配置文件。你需要手动把源码包里的redis.conf复制到/etc/redis/redis.conf，然后自己写 service 文件，或者干脆每次手动启动。我之前的一贯做法是手写 service 文件，这样就能像 apt 安装版一样用 systemctl 管理。模板文件内容如下：

[Unit] Description=Redis In-Memory Data Store After=network.target [Service] ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf ExecStop=/usr/local/bin/redis-cli shutdown Restart=always User=redis Group=redis RuntimeDirectory=redis RuntimeDirectoryMode=0750 [Install] WantedBy=multi-user.target

记得先创建 redis 系统用户：sudo useradd --system --no-create-home --shell /bin/false redis，然后把 redis.conf 文件的所有者改成 redis，否则启动时会遇到权限问题。

编译安装的优点不言而喻，最新版本、编译选项完全可控。代价就是这些额外的配置工作。对于只是想本地跑个 Redis 的人来说，这一步的投入产出比并不划算，请自行斟酌。

3.3 Docker 方式：一行命令跑一个隔离的 Redis

如果你已经在用或者打算用 Docker，这种方式是最轻量的。前提是 Docker 已经装好并启动，然后执行：

docker run -d \ --name redis-local \ -p 6379:6379 \ -v redis-data:/data \ redis:7.4-alpine

这条命令会拉取官方的 Redis 镜像，启动一个名为 redis-local 的容器，把容器的 6379 端口映射到宿主机的 6379 端口，同时挂载一个名为 redis-data 的卷来持久化数据。如果没有挂载数据卷，容器删除后数据就丢了，这个细节千万别忽略。

进入容器内部执行命令的方式是docker exec -it redis-local redis-cli，接下来在容器里操作 Redis 跟在宿主机上操作没什么区别。

Docker 方式最大的价值是环境隔离。你可以在同一台机器上跑多个 Redis 实例，分别对应不同项目，互不干扰。需要清理时docker rm -f redis-local就完事了。如果你喜欢反复折腾实验环境，这种方式比源码编译再卸载来得痛快得多。对于分布式环境里的主从复制和集群模拟，Docker 也是绝佳的平台——后面配置主从时甚至可以直接docker run再起一个容器来当从节点，方便得很。

4. 核心配置解析：改好这些参数才算真正会用

4.1 redis.conf 里的关键配置项逐行解读

Redis 的配置文件默认位于/etc/redis/redis.conf，无论哪种安装方式，只要是用配置文件启动的，核心配置项都是同一套。我用一个实际的调整案例来演示怎么改。

先备份原始配置：sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak。这个习惯非常推荐，Redis 配置项有一百多个，新手很容易改出问题，备份就是后悔药。

打开配置文件后，按优先级调整以下几项：

# 绑定监听地址，127.0.0.1 表示只有本机能连 bind 127.0.0.1 # 保护模式，默认开启 protected-mode yes # 配置访问密码，建议在生产环境一定设置 requirepass yourstrongpassword # 端口号，默认 6379 port 6379 # 最大可用内存，单位字节，生产环境建议设置 maxmemory 256mb # 内存淘汰策略 maxmemory-policy allkeys-lru # 持久化上的配置 appendonly yes

bind、protected-mode、requirepass 这三项是安全铁三角。bind 指定 Redis 监听在哪个网络接口上，默认的 127.0.0.1 意味着外网无论如何都连不上。如果你需要局域网访问，可以改成bind 0.0.0.0，但改了以后必须同时设置密码，否则就像没关门就出门——谁都能进来。protected-mode 是 Redis 的自我保护机制，当它检测到你在没有密码且监听所有接口的情况下工作时，会拒绝外部连接请求。如果你遇到“本地能连，外面连不上”的怪现象，十有八九是 protected-mode 在帮你挡攻击。

maxmemory 和 maxmemory-policy 是关于内存的配置。Redis 作为缓存层时，内存是它的上限，没限制的话它会一直占用内存直到系统崩溃。设置 maxmemory 后，数据量达到上限就要决定“把哪些数据踢出去”，也就是淘汰策略。allkeys-lru 是最常用的，意思是所有 key 按照最近最少使用原则淘汰，适合纯粹的缓存场景。如果 Redis 里数据要完整保留，则不应该开启淘汰策略，而是要加节点扩容。附录中我还会给出不同场景下的配置推荐。

appendonly 是 AOF 持久化的开关。Redis 默认快照模式（RDB）是将内存中的数据定期存到磁盘，可以接受短时间的数据丢失；AOF 模式则是把每一条写命令都追加到日志文件，数据可靠性更高，但磁盘占用也更大。能接受数据丢失的场景就保持默认不开 AOF；重要的业务数据建议开启。两种模式可以同时启用，Redis 启动时会优先用 AOF 文件恢复数据。

4.2 密码认证和安全设置的必备习惯

设置密码这事，开发环境里很多人嫌麻烦，这是非常危险的坏习惯。Redis 默认不设密码，只要端口暴露在网络上，任何人都可以连上去执行 flushall 清空数据。这在公网上每隔几分钟就会被扫描器爬一次。

设置密码的方式是在 redis.conf 里加一行：

requirepass 你的强密码

然后重启服务。如果不想走配置文件重启，可以直接在客户端里执行CONFIG SET requirepass 你的密码，这个命令可以运行时临时修改，但不会写入配置文件，重启后失效。生产环境里的建议是，两步都做——文件配好、同时运行时立刻设置，保证当前马上生效。

设置了密码之后，redis-cli 的用法会有一点变化。直接执行redis-cli ping会返回 NOAUTH 错误，需要用redis-cli -a 你的密码 ping带密码访问。这里有个很实用的技巧：在 redis-cli 里执行AUTH 你的密码，输入正确后就进入正常状态了。命令行里带密码会留下历史记录，安全性要求高的环境建议使用REDISCLI_AUTH环境变量来避免密码出现在进程列表里。

还有一个大家容易忽略的安全习惯：对外暴露的时候记得改端口。默认的 6379 端口是全宇宙扫描器最喜欢敲门的地方，改成 8379、9379 之类的高位端口，能有效减少被自动化工具盯上的概率。这不是什么高深技巧，但确实是最省事的防攻击手段之一。

4.3 systemd 管理方式与开机自启的原理

Ubuntu 的 apt 安装会自动注册 systemd 服务，这也是新手最省心的地方。相关操作命令如下：

# 启动服务 sudo systemctl start redis-server # 停止服务 sudo systemctl stop redis-server # 查看运行状态和最近日志 sudo systemctl status redis-server # 设置开机自启 sudo systemctl enable redis-server # 取消开机自启 sudo systemctl disable redis-server # 修改配置后重启服务让配置生效 sudo systemctl restart redis-server

需要特别注意的是，修改 redis.conf 后，一定要用 restart 重启服务，用 reload 虽然 systemd 会重新读取配置，但 Redis 对某些配置项在 reload 时的行为并不可靠。我在这上面栽过跟头，以为 reload 就生效了，结果 requirepass 改了根本没应用，排查了半天才发现问题。

查看系统日志是排查故障的重要手段，journalctl -u redis-server -n 50可以看最近 50 行 Redis 的日志。不少问题光看报错信息就能找到原因，比如 Redis 报告内存不足、持久化失败、权限错误，日志里都会写得很清楚。

5. Redis 基础使用与真实业务场景演练

5.1 redis-cli 基础操作：最常用的命令一网打尽

Redis 装好后，使用入口主要是两个：redis-cli 命令行工具和各种语言的客户端库。先从命令行讲起，因为命令行是理解数据结构和命令行为的直观入口。

启动 redis-cli 后，你可以试着输入下面几条命令：

# 写入一个字符串 SET username "zhangsan" # 读取值 GET username # 设置过期时间，单位秒 SET verify_code "123456" EX 60 # 查看剩余存活时间 TTL verify_code # 判断 key 是否存在 EXISTS username # 删除 key DEL username

这些都是 Redis 最基础的操作。注意 SET 命令后面的 EX 参数——这个是高频使用技巧，缓存场景下基本每次写入都要带过期时间，这样 Redis 会自动清理，不需要你半夜爬起来手动删。

查看当前数据库里有多少 key，用DBSIZE；清空当前库用FLUSHDB；清空所有库用FLUSHALL。这两个危险操作，生产环境千万别乱按，按完数据就没了，没有回收站。

5.2 五种核心数据类型逐一演示，用生活场景理解

Redis 之所以比普通缓存工具强，是因为它不只是 key-value，而是提供了五种随手可用的数据结构。我用具体例子让你一次明白。

字符串（String）是最基础的，缓存用户基本信息、验证码、网站配置项都能用它。

列表（List）是一个双向链表，适合当队列用。左边塞任务右边取任务，天然实现一个 FIFO 的轻量消息队列。比如订单模块把待处理操作 LPUSH 进队列，另一个进程不断 RPOP 出来执行。

LPUSH task_queue "task1" RPOP task_queue

哈希（Hash）很适合存对象。一个用户的信息不用拆成十个字符串 key，直接存进一个哈希里。相比把整个对象序列化成 JSON，哈希字段还能单独更新，不用整存整取，省流量也省时间。

HSET user:1001 name "李四" age 18 city "北京" HGET user:1001 name

集合（Set）的用处是去重和做关系运算。网站的标签系统，一个用户关注了哪些话题，直接存成一个集合。两个集合之间可以做交集并集差集，比如“同时关注了话题A和话题B的用户”可以直接用 SINTER 算出来。

有序集合（ZSet）是 Redis 里最值钱的数据结构。它既像一个 Set 能去重，又给每个成员关联了一个分数，按分数自动排序。排行榜、延迟队列、限流窗口都能用它实现。排行榜的经典用法：

ZADD leaderboard 100 "player1" ZADD leaderboard 89 "player2" ZINCRBY leaderboard 5 "player1" ZREVRANGE leaderboard 0 9 WITHSCORES

ZINCRBY 是原子自增，多台服务器并发给同一玩家加分也不会错乱。这是做排行榜最顺滑的方案，没有之一。

5.3 从数据缓存到分布式锁：看懂一个完整的落地案例

只学会命令不代表会用 Redis，我来拆解一个最典型的小项目场景：设计一个带分布式锁的秒杀接口。

假设你有两台服务器同时处理秒杀请求，用户点了抢购按钮，两个请求同时到了两台服务器上，这时候要保证同一个用户只能被处理一次。最简单的方案就是用 SETNX 命令。SETNX 的意思是“只有当 key 不存在时才设置成功”，这个原子操作天然就是锁的雏形。

# 尝试获取锁 SETNX lock:user:1001 1 # 返回 1 表示抢锁成功，返回 0 表示别人已经持有锁

但有锁还不够，要防死锁。如果获取锁的服务请求处理到一半崩了，锁永远得不到释放，其他人就要排队等一辈子。解决办法是设置锁的过期时间：

SET lock:user:1001 1 EX 10 NX

这个命令的效果是：只有当 key 不存在时才能设置成功，且自动带上 10 秒过期时间。就算持有锁的服务挂了，最多 10 秒锁也会自动释放，不会造成永久死锁。这就是企业里最常用的分布式锁方案雏形，很多工程框架实现的锁底层就是这一行命令。

在实际的秒杀场景中，拿到锁之后还需要在 Redis 里检查库存并扣减。比如：

DECR stock

DECR 是原子减一。多个客户端同时执行 DECR 时，Redis 内部会保证串行执行，不会出现两个人同时买到同一件商品的问题。这就是“Redis 能做中间件”的底层逻辑。

5.4 图形化工具推荐：Redis Insight 更适合新手观察数据

命令行用久了你会发现，调试复杂数据结构时眼睛很累。Redis 官方目前主推的图形化工具是 Redis Insight（之前叫 RedisInsight），它支持桌面独立客户端和 Web 版两种形态。

Redis Insight 最大的价值是可视化。你可以在界面上看到所有 key 的列表、类型、大小、过期时间，还能直接浏览各数据结构的内容，甚至提供了内嵌的命令行交互面板。新手用它来学习命令、观察过期机制和数据淘汰的过程，效率比纯命令行高一个量级。

连接配置时填上服务器 IP、端口、密码就行。如果在本地连远程服务器的 Redis，记得先确认 bind 配置已经允许对应网段访问，防火墙也放行了端口。图形化工具的用途主要是在开发和调试阶段，生产环境的运维监控建议还是用 Prometheus 那套体系，那是另外一个话题了。

6. 新手最容易踩的坑，都替你整理好了

6.1 连接失败问题：为什么本地能连、外面连不上？

这是新手问得最多的问题，没有之一。症状很明显：在服务器本机上用 redis-cli ping 返回 PONG，从另外一台机器连却报 connection refused 或者超时。百分之八十的原因是 Redis 只监听了回环地址。检查办法是看 redis.conf 里的 bind 配置，如果是bind 127.0.0.1就说明外部网络访问不来。

修改为bind 0.0.0.0后，还要确认防火墙没有挡端口。Ubuntu 检查防火墙命令：

sudo ufw status

如果输出显示 ufw 已启用，你需要放行 Redis 的端口：

sudo ufw allow 6379/tcp

如果防火墙没开还要确认云平台的安全组规则。阿里云、腾讯云这种云服务器一般有两层过滤：系统防火墙是一层，云控制台的安全组是另一层。很多人在系统里折腾半天，最后发现是安全组没放行端口。

连接超时的问题如果发生在跨机房或者跨地域环境，还要考虑 Redis 本身没有加密传输，长距离传输内容很容易被截获，这种情况下建议只在受信内网里部署，不要在公网环境裸奔。

6.2 密码认证失败：NOAUTH 报错的处理姿势

执行命令时报NOAUTH Authentication required，说明你没提供密码或者密码错误。处理方法是执行 AUTH 命令：

AUTH yourpassword

这里有个非常常见的踩坑点：如果你的密码里包含特殊字符，比如!或@，在命令行执行redis-cli -a 'p@ss!word'时要用单引号把密码包起来，否则 shell 会对特殊字符做解析，密码就“变味”了。更稳妥的做法是不用 -a 参数，先进去再 AUTH，避免密码出现在进程列表里。

还有一个坑是配置文件改了 requirepass 但忘了重启服务，当场测试一直报错。所以改了密码一定先systemctl restart redis-server再测试。

6.3 内存爆满与淘汰策略的选择逻辑

不设置 maxmemory 的 Redis，会在你不知不觉中吃掉整台机器的内存，然后操作系统开始用交换分区，整个系统卡成 PPT。设置 maxmemory 之后，Redis 在内存达到上限时开始执行淘汰策略。根据业务场景不同，策略选择可以完全不同：

新手最容易困惑的是把 maxmemory 设得过大，比如给 Redis 分配 8GB，但系统内存总共才 8GB，结果 Redis 启动几分钟后系统整体崩溃。建议 maxmemory 不要超过系统内存的 60% 到 70%，要给操作系统和其他进程留足余量。生产环境里我习惯先压测估出 Redis 的实际占用，再反推该给多少内存，而不是拍脑袋定个值。

6.4 数据没了之谜：RDB、AOF 和持久化的正确姿势

有新手发现：Redis 重启后，以前的数据全没了。这个问题的根源几乎都是持久化配置不对。Redis 默认开启的是 RDB 快照持久化，它的触发条件是“多少秒内有多少次写操作”，比如默认配置是 900 秒内至少有 1 次写操作才会生成快照。如果你写了几条数据，重启间隔又很长，但期间写操作没达到触发阈值，快照完全有可能没生成，重启后自然一片空白。

如果数据重要，把 AOF 打开：

appendonly yes appendfsync everysec

appendfsync 可以配 always、everysec、no。always 是每个写命令都同步到磁盘，最安全但最慢；everysec 是每秒刷一次盘，性能和安全性比较均衡；no 是交给操作系统决定何时写盘，性能最好但丢数据的风险最大。生产环境推荐 everysec，最多丢一秒数据，不会对业务造成灾难性影响。RDB 和 AOF 可以同时开，Redis 启动时会优先用 AOF 文件来恢复数据，因为 AOF 的数据更完整。

6.5 慢查询的快速定位技巧

当你感觉 Redis 变慢时，先去查慢日志。Redis 自带慢查询日志，配置两个参数：

slowlog-log-slower-than 10000 slowlog-max-len 128

上面的意思是记录超过 10000 微秒（10 毫秒）的命令，最多保留 128 条。用SLOWLOG GET 50可以查看最近 50 条慢命令。排查步骤是先看是不是某个命令本身复杂度过高，比如 KEYS 这个命令在新手阶段用得特别多，但它在生产环境里是危险命令，因为会遍历所有 key，造成 Redis 阻塞。线上环境应该用 SCAN 命令代替 KEYS，SCAN 是分批遍历的，不会卡死服务。

6.6 其他常见问题速查表

7. 个人经验与后续学习建议

装好 Redis 只是入门第一步，真正提高的方式是把它丢到实际项目里去“练”。我个人的建议是，装好后不要急着删了重装，先找个简单业务试试手：比如给你自己的个人网站加一个访问计数，写一个脚本往 Redis 里塞数据再清理，模拟一下秒杀场景的并发请求。Redis 的命令很多，完整文档有上百个命令，没必要一次记全，把 String、List、Hash、Set、ZSet 这五种数据结构相关的常用命令练熟，覆盖日常 80% 的用法已经绰绰有余。

稍微进阶一点，可以尝试在主从复制上加深理解。在另一台机器或者另一个 Docker 容器里启动一个 Redis 实例，把replicaof配上，让从节点同步主节点的数据。理解了主从复制，后面再去看哨兵、集群这些高可用方案，感觉就会顺畅得多。

最后一条建议：无论如何，不要在公网上运行一个没有密码的 Redis。这是我说的最认真的一句，一旦中招，数据被清空、被勒索都不是开玩笑的事。顺手把密码、防火墙、绑定地址这三件事做对，后面能省掉非常多麻烦。