Redis服务端与客户端命令全解析：从启动连接到数据操作与排查

不少人第一次接触 Redis，都是从redis-server和redis-cli这两个命令开始的。一个负责把服务端跑起来，一个负责连上去敲命令，听起来简单，真正用起来却发现有不少门道。最近我把 Redis 服务端和客户端命令重新梳理了一遍，发现很多人在安装完 Redis 之后，卡在第一关：服务端启动成功了，客户端却死活连不上；客户端好不容易连上了，又不知道先敲哪个命令、为什么有的命令在生产环境不能碰。这里就围绕“服务端和客户端命令”这个主题，把两端的常用命令、背后原理、实际场景下的组合用法一次性讲透，适合刚装完 Redis 准备上手的初学者，也适合那些用了一段时间 Redis、但对命令背后的设计逻辑还想再确认一遍的开发者。

先说明一点：标题里说的“服务端命令”，其实包含两个层面的意思。一个是操作系统层面启动、管理 Redis 服务进程的命令，比如redis-server、redis-cli shutdown；另一个是你用客户端连上 Redis 之后，执行那些管理系统状态、配置、运行信息的命令，比如INFO、CONFIG GET、SLOWLOG。而“客户端命令”则指操作数据的各种命令，GET、SET、LPUSH、ZADD都属于这一类。很多人分不清，是因为这两类命令的边界并不在语法上，而在“谁来执行、作用对象是谁”上。这篇文章就从这里说起。

1. 先搞清楚 Redis 的两端：服务端和客户端到底是什么关系

1.1 Redis 不是“一个程序”，而是一套服务模型

Redis 在大多数人的印象里就是“一个内存数据库”，装好之后运行一个程序，然后去读写数据。但它实际上遵循的是经典的 client-server 架构：一个独立的服务端进程负责存储数据、处理请求，多个客户端进程通过网络协议和它通信，发送命令、接收结果。

这个过程可以类比成你去饭店吃饭：服务端是后厨，负责把食材变成菜品；客户端是点菜窗口，你在这里报菜名、等上菜；命令本身就是菜单上的条目，每一条都有明确的语法和返回格式。Redis 的默认通信端口是 6379，客户端和服务端通过 TCP 连接进行交互，传输的内容遵循 Redis 自己定义的 RESP 协议。大部分时候你不必关心 RESP 的具体格式，客户端工具已经帮你封装好了，但理解这条链路很重要：所有你敲下去的命令，最终都是通过网络发给服务端进程去执行的，而不是在客户端本地跑的。

这一点是理解服务端命令和客户端命令区别的基础。比如你执行redis-cli INFO，实际上是redis-cli这个客户端程序连上服务端，发了一条INFO命令，服务端执行完把内存、连接数、持久化状态这些信息打包返回给你。而如果直接执行redis-server，则是把服务端进程本身启动起来，它开始监听端口、等待客户端接入。两个命令的主角不同，但经常被放在同一份教程里讲，就是因为它们的联合使用构成了 Redis 最基本的运维操作。

1.2 服务端命令和客户端命令的界限在哪里

很多刚接触 Redis 的朋友会困惑：CONFIG SET到底是服务端命令还是客户端命令？从执行者的角度看，它是在客户端里敲的，但作用对象是服务端运行时配置，所以它属于“管理服务端状态的命令”。为了方便，通常可以按“目的”做区分：

• 启动类命令：你在 Shell 里执行的redis-server、redis-sentinel，作用是把服务端进程拉起来，属于操作系统层面的命令。
• 管理类命令：通过客户端连上之后，对服务端做状态查看、配置修改、日志排查，比如INFO、CONFIG、SHUTDOWN、CLIENT LIST。
• 数据操作类命令：对 Redis 里的键和值进行操作，比如SET、GET、DEL、HSET，这是日常开发中使用频率最高的一类。

把这三类命令分清楚，后面学起来会轻松很多。而且在面试里也经常考到这个点，比如“Redis 的 shutdown 命令做了什么？为什么比直接 kill 进程安全？”这种问题，本质上就是在考察你对服务端命令执行机制的理解。接下来就按这个分类，把实际操作中最常用的命令逐个过一遍，每一步都附上参数、原理和我的踩坑记录。

2. 服务端命令：启动、守护、查看、关闭一个都不能少

2.1 用 redis-server 启动服务端以及后台守护的关键参数

Redis 安装完之后，可执行文件里最重要的两个就是redis-server和redis-cli。前者是服务端程序，后者是客户端程序。很多人直接运行redis-server，发现终端被“占住”了，全是日志输出，想敲别的命令只能再开一个窗口。这是因为默认情况下 Redis 以前台模式运行，进程直接挂在你当前的终端上。

要让它转到后台运行，两种方式最常见。第一种是在启动命令里加参数：

redis-server --daemonize yes

daemonize直译是“守护化”，意思就是把进程变成守护进程，脱离当前终端，在后台静默运行。启动后它会返回一个 PID，日志也不再往终端打了，而是按配置写入日志文件。第二种方式是修改配置文件redis.conf，把里面的daemonize yes这一行的注释去掉，然后通过redis-server /path/to/redis.conf启动。我用下来更推荐第二种，因为 Redis 的配置项很多，bind、port、requirepass、maxmemory这些关键参数如果每次都在命令行里拼，既容易出错，又不好维护。

启动服务端时还有几个参数你会高频用到：

# 指定端口启动 redis-server --port 6380 # 指定绑定的网卡地址 redis-server --bind 0.0.0.0 # 设置密码 redis-server --requirepass mypassword # 指定配置文件启动 redis-server /etc/redis/redis.conf

有个细节必须提醒：命令行参数优先级高于配置文件。也就是说如果你在命令里写了--port 6380，配置文件里就算写了port 6379，最终生效的也是 6380。这个特性在排查“为什么我改了配置不生效”的时候特别重要，很多人查半天，最后发现是启动脚本里带了旧的参数。

2.2 redis-cli shutdown 为什么比 kill 更安全

关闭 Redis 服务端，我见过不少人直接kill -9进程号，这种方式狠是狠，但会带来数据丢失风险。Redis 虽然不是强持久化系统，但如果配置了 AOF 或 RDB，kill -9会让进程来不及做清理和持久化收尾，极端情况下可能丢数据或者留下不完整的 AOF 文件。

正确做法是用客户端命令优雅地关闭：

redis-cli shutdown

如果服务端设置了密码，还要加上认证参数：

redis-cli -a yourpassword shutdown

SHUTDOWN命令的执行逻辑是先停止接收新的请求，然后根据配置决定是否执行持久化操作，最后再退出进程。整个过程是“有序撤退”，而不是“突然断电”。如果你执行完 shutdown 后想确认进程还在不在，可以再运行一次redis-cli ping，正常情况下会返回连接失败，因为端口已经关闭了。

这里再补充一个容易忽略的细节：SHUTDOWN支持一个可选的NOSAVE参数，比如redis-cli shutdown nosave，意思是关闭前不执行持久化保存。什么时候用？如果你明确知道现在的数据不重要，或者持久化文件写不进去导致关闭流程卡住，可以用这个参数强制跳过保存步骤直接退出。但注意这是特殊情况，不要养成习惯，否则 Redis 变成了纯内存数据库，宕机就全没了。

2.3 查看服务端状态：INFO、CONFIG、MONITOR 各有各的用

服务端跑起来之后，最需要通过客户端命令确认它“到底健康不健康”。每次我接手一个陌生的 Redis 实例，第一件事永远是执行redis-cli INFO，把输出从头到尾扫一遍。

INFO命令可以带 section 参数，只查某一部分信息，省得刷屏：

# 查看服务器基本信息 redis-cli INFO server # 查看内存使用情况 redis-cli INFO memory # 查看客户端连接情况 redis-cli INFO clients # 查看持久化状态 redis-cli INFO persistence # 查看复制（主从）状态 redis-cli INFO replication

我比较关注的是INFO memory里的used_memory和maxmemory。前者是当前实际占用的内存，后者是配置允许的上限。如果两者非常接近，说明 Redis 内存快要爆了，接下来配置的淘汰策略会开始工作，这是排查线上问题时的高频切入点。

CONFIG GET和CONFIG SET是另一组管理命令，作用是动态读取和修改运行期配置。比如线上突然想临时调整最大内存限制：

# 查看当前最大内存 redis-cli CONFIG GET maxmemory # 临时调整为 256MB redis-cli CONFIG SET maxmemory 256mb

注意CONFIG SET修改的是运行时配置，如果不执行CONFIG REWRITE写回配置文件，重启之后会恢复原样。这个特性有时候是优点——测试环境随便改，不怕污染配置文件；但生产环境就要谨慎，改完了一定要有记录，否则重启后配置漂移，问题非常难查。

MONITOR命令适合在调试阶段开启，它会实时打印服务端收到的每一条命令：

redis-cli MONITOR

但千万别在生产环境长时间挂着。它会持续输出所有命令，消耗大量 I/O 和 CPU，而且输出内容可能包含敏感数据。我的一次教训是，开着 MONITOR 排查问题，结果线上流量太大，终端滚动到眼睛发花，还拖慢了服务端，后来只在小流量时段开几秒钟看个快照。

3. 客户端命令：连上 Redis 之后怎么操作数据

3.1 建立连接：redis-cli 的常用连接参数

Redis 的所有操作最终都要通过客户端发起，redis-cli是最基础、最通用的客户端工具。它支持很多连接参数，日常使用最频繁的是下面这几个：

# 指定 IP 和端口连接 redis-cli -h 192.168.1.100 -p 6379 # 连接并认证 redis-cli -h 192.168.1.100 -p 6379 -a yourpassword # 选择指定编号的数据库（默认 0-15） redis-cli -n 2 # 以原始格式输出结果，避免中文等字符被转义 redis-cli --raw

-n参数在 Redis 配置了多个逻辑库的情况下很有用。Redis 默认有 16 个数据库，编号从 0 到 15，同一个 Redis 进程里可以承载多套业务数据，用库号做隔离。不过现在主流实践都不推荐多库了，一个业务一个 Redis 实例或者用 key 前缀区分更清晰。但如果你接到老项目，里面用了db1、db2，就得靠-n参数切换，这个技能逃不掉。

连接成功之后，可以先用PING命令做一次连通性测试。服务端如果能正常通信，会返回PONG。我在排查“客户端连不上”时，第一步就是redis-cli ping，如果返回PONG，说明网络和服务端进程都没问题；如果卡住或者报错，再检查防火墙、bind配置、protected-mode这些原因，不然后面敲再多数据命令都是白费。

3.2 键空间命令：管理 key 的生命周期

客户端命令里使用频率最高的一类，其实是针对“键”本身的命令。Redis 是键值数据库，所有数据都挂在一个 key 下面，所以对键的操作直接影响着数据存储和淘汰策略。

基础命令好理解：

# 写入字符串 SET user:01 "张三" # 读取 GET user:01 # 判断是否存在 EXISTS user:01 # 删除 DEL user:01

更关键的是带过期时间的命令。做缓存治理时，你一定逃不开EXPIRE：

# 给 key 设置 60 秒过期时间 EXPIRE user:01 60 # 查看剩余存活时间（TTL） TTL user:01 # 上面 ttl 返回 -2 表示 key 不存在，-1 表示没有设置过期时间

这套命令在 Redis 做分布式锁的时候尤其重要。经典的分布式锁实现是SET key value NX EX，其中NX表示只有 key 不存在时才设置成功，EX表示同时设置过期时间。很多人只记命令用法，不理解为什么EX必不可少——因为如果锁没有过期时间，持有锁的进程崩溃了，锁永远不会释放，其他进程只能死等。这个细节也是面试题里的常客。

这里有个从小到大都在强调的坑：KEYS命令不要在生产环境用。

# 不要这样 KEYS user:* # 用这个替代 SCAN 0 MATCH user:* COUNT 100

KEYS会遍历所有 key，在键数量很大的情况下会阻塞 Redis 服务端，导致请求排队，严重时就是一次线上事故。SCAN是游标式的增量遍历，每次返回少量结果，不会阻塞主线程。我从接手第一个生产 Redis 开始就被反复叮嘱，现在也把它写进自己的检查清单里，每次排查数据前先提醒自己“用 SCAN，不用 KEYS”。

3.3 数据类型命令：五大类型各有各的玩法

Redis 之所以强大，不只是因为它快，更因为它提供了丰富的数据类型。面试围着一个核心概念反复考，就是“Redis 支持哪几种数据类型、各自适用什么场景”。对应到命令上，每种类型都有一批专属的操作。

String 类型最常见，最基础的SET、GET之外，还有INCR、DECR这类原子自增命令。做计数器、限流器时它们非常好用，因为INCR的原子性由 Redis 单线程模型保证，不需要你额外加锁。注意如果 key 的值不是整数，INCR会报错，所以写入前要保证内容可解析为数字。

Hash 类型适合存对象，比如用户信息、商品信息。它允许你在一个 key 下面维护多个字段，不需要每次都序列化整个对象：

HSET user:02 name "李四" age 30 HGET user:02 name HGETALL user:02

List 类型是双向链表，适合做消息队列、时间线等场景。常用命令是LPUSH、RPUSH、LPOP、RPOP和LRANGE。做简单的先进先出队列，就是左边进、右边出：

LPUSH queue:task "job1" RPOP queue:task

Set 类型是无序集合，天然支持去重和集合运算，适合做标签系统、共同好友这类场景。SADD添加成员，SREM删除成员，SINTER求交集，SUNION求并集，一行命令就能完成分组统计。

ZSet 类型在 Set 的基础上给每个成员附加了分数，按分数排序，适合做排行榜。命令模式是ZADD key score member，查询用ZRANGE或ZREVRANGE。做“过去 24 小时热搜榜”这类需求，ZSet 几乎是首选，因为它既能存储数据，又天然有序，排序逻辑由 Redis 内部完成。

五种数据类型放在一张表里看更清楚：

每个类型的命令都不止这几个，但把这批常用命令吃透，日常开发已经能覆盖七成以上的场景了。我建议学习顺序是先用 String 把缓存读写跑通，再逐个尝试其他类型，每个类型造一点测试数据练一练，比单纯背命令列表有效得多。

3.4 服务端接口测试场景下的命令组合

“服务端接口测试”是很多后端开发会遇到的工作，而 Redis 在这类场景里经常扮演着“数据速查器”的角色。测试接口时，你请求打到服务端，服务端可能会往 Redis 里写缓存、写消息队列、记录请求日志。为了验证接口是否工作正常，最直接的方法就是连上 Redis 查一下关键数据。

我常用的排查套路是这样：

# 查所有 key（小流量测试环境可以用 KEYS，生产环境用 SCAN） KEYS order:* # 看某个 key 的剩余过期时间，判断缓存是否设置成功 TTL order:20250101 # 直接读取 value，确认写入内容是否符合预期 GET order:20250101 # 如果数据是 hash 结构，看所有字段 HGETALL order:20250101 # 如果写的是 list 队列，看队列长度和头部数据 LLEN queue:payment LRANGE queue:payment 0 10

这套组合拳在联调和问题定位时特别管用。比如测试一个“下单成功后写支付消息”的接口，如果LLEN queue:payment返回 3，说明三条消息已经进去了；如果返回 0，就要看看是接口逻辑没执行到，还是 Redis 写入失败被吞了。

另外，接口测试时经常需要“清场”——把上一次测试留下的脏数据清掉。清理单个 key 用DEL，清理当前库全部数据用FLUSHDB，清理所有库用FLUSHALL。这两个清库命令在生产环境是禁词，但在测试环境非常常用。我自己的习惯是在执行清库前，先redis-cli -n 库号 SELECT 库号确认自己连的是不是测试环境，否则手一抖把别人正在用的数据清了，那体验相当酸爽。

4. 可视化客户端与命令行的取舍：连接工具怎么选

4.1 常用可视化客户端对比与连接配置

命令行虽然强大，但看数据时体验确实一般，尤其是 hash、zset 这类结构化数据，一屏滚动下来眼睛都花了。可视化客户端就是来解决这个问题的，这些年我用过不少，比较有代表性的几款可以给个参考：

可视化客户端的连接配置，本质上和命令行连接参数是一一对应的。填 IP、端口、密码，有些还支持 SSH 隧道、TLS 加密传输。这里提醒一句：如果你在本地通过可视化工具连远程服务器的 Redis，一定要确认服务器的bind配置和防火墙规则允许你的 IP 访问，不要为了方便把bind设成0.0.0.0然后裸奔。Redis 默认开启了protected-mode，在没有密码的情况下，只允许本机回环地址连接，这是默认的安全防线。

4.2 哪些场景必须回到命令行

可视化工具再好用，也替代不了命令行，原因有几个。

首先是生产环境。很多服务器上根本没有图形界面，你只能通过 SSH 登录上去，在终端里执行命令。除非公司专门搭了运维平台，否则生产环境的数据查看、故障排查基本都靠命令行完成。这是我最开始不适应、后来被逼着练出来的技能。

其次是批量操作。可视化工具适合“点一点、看一看”，但涉及批量设置过期时间、批量删除前缀相同的 key、统计某个类型的数据量时，命令行配合脚本的效率高出一个量级。比如清理某个业务前缀的所有测试数据：

redis-cli --scan --pattern "test:*" | xargs -r -L 100 redis-cli DEL

这条命令先用SCAN游标式地扫描出所有匹配test:*的 key，再通过管道交给DEL分批删除。比起在可视化界面里一个个右键删除，不知道快了多少倍。

最后是技术深度。很多高级排查手段，比如查看慢查询、分析大 key、查看连接详情，可视化工具虽然也有入口，但命令行的输出更直接、更完整。从学习和面试的角度，命令行也是绕不开的，因为面试官不会问你“Redis Desktop Manager 的下载地址是什么”，而是问你SLOWLOG GET怎么用、redis-cli --bigkeys能查出什么。工具可以是辅助，但基本功必须落在命令行上。

5. 常见问题与排查技巧实录

5.1 服务端启动失败与端口占用

刚装的 Redis 经常遇到启动报错或者闪退。最常见的几个原因：

• 端口被占用。启动时如果提示Address already in use，说明 6379 已经被其他程序占用了。这时候要么改端口，要么找到占用进程处理。排查命令可以用netstat -tlnp | grep 6379或者lsof -i:6379。
• 配置文件路径不对。用redis-server /path/redis.conf启动时，如果文件不存在或权限不足，服务端会直接报错退出。
• 内存不足或系统限制。Redis 启动时可能因为maxmemory设置过高、vm.overcommit_memory内核参数限制等原因起不来，日志里会有明确提示。

排查时记住一个原则：先看日志文件，再猜问题。Redis 默认日志输出到stdout，但如果配置了logfile，会把日志写到指定文件。日志里的错误信息比任何猜测都靠谱。

5.2 客户端连接被拒绝：bind、protected-mode 和防火墙

客户端连不上 Redis，十个里面有八个是这三类问题。

bind配置限制了监听地址。如果redis.conf里只写了bind 127.0.0.1，那只有本机可以连，其他机器发起的连接会在 TCP 层面就被拒绝。需要对外服务时，把bind改成0.0.0.0或者具体的网卡 IP。注意改成0.0.0.0之前要配合密码认证，不然后果相当危险。

protected-mode是 Redis 的一个保护机制。在没有配置密码且没有修改bind的情况下，它只允许回环地址连接。很多人在本地连接正常，部署到云服务器后突然连不上，排查思路里一定要加上这个参数。

防火墙也不能忽略。云服务器安全组、本地防火墙都可能拦截 6379 端口的入站流量。检查命令在 Linux 上通常是：

# 查看防火墙状态 firewall-cmd --list-all

如果开了防火墙，需要放行端口。这类问题用redis-cli -h 目标IP -p 6379 ping测试时，表现往往是“连接超时”，而不是“认证失败”，这是区分网络问题和认证问题的重要线索。

5.3 密码与认证：NOAUTH 和 WRONGPASS 的应对

如果服务端配置了requirepass，客户端连接后执行任何数据命令前必须先认证。未认证时会报(error) NOAUTH Authentication required.，意思是“需要认证”。这时执行：

AUTH yourpassword

或者直接连接时带-a参数：

redis-cli -a yourpassword

如果密码本身错了，会返回WRONGPASS invalid username-password pair or user is disabled。这种报错很直白，就是密码不对。但有个坑要提醒：密码里有特殊字符时，Shell 可能会做转义。比如密码是abc$123，在命令行里写-a 'abc$123'时要加单引号，否则$123会被 Shell 当变量展开，你传过去的密码就不是你以为的那个了。

5.4 内存淘汰与缓存治理：maxmemory 和淘汰策略

线上 Redis 最常见的问题之一就是内存不够。当used_memory达到maxmemory上限后，Redis 会按照配置的淘汰策略开始“踢”数据。默认策略是noeviction，意思是内存满了之后，写命令直接报错，不淘汰任何 key。很多项目上线时没注意这个配置，结果缓存一满，新的写入全部失败，表现就是接口突然大面积报错。

排查时用INFO memory看当前占用，再用CONFIG GET maxmemory-policy看淘汰策略。需要临时调整策略时，可以：

redis-cli CONFIG SET maxmemory-policy allkeys-lru

allkeys-lru的含义是从所有 key 里按最近最少使用原则淘汰。但注意策略选择要匹配业务：如果只是做缓存，allkeys-lru可以接受；如果 Redis 里还存着一些不能丢的数据，就要谨慎，或者考虑改用volatile-lru（只淘汰设置了过期时间的 key）。这套设计也经常作为缓存治理的面试题，考察的点就是“你懂不懂淘汰策略对业务的影响”。

另外，排查大 key 也是一个经常被忽略的步骤。一个巨大的 hash 或者 list 会让 Redis 在操作它时长时间阻塞，拖垮整个实例。排查利器是：

redis-cli --bigkeys

它会对所有 key 做一次扫描，统计出每种类型占用空间最大的 key。这个命令在生产环境跑也有一定压力，建议放在业务低峰期执行。

5.5 Docker 部署 Redis 后的客户端连接方式

现在用 Docker 装 Redis 的场景越来越多，热词里也有“docker安装redis主从”。Docker 部署带来的新问题是：容器内部的客户端和宿主机外面的客户端，连接方式不一样。

容器内部连接很简单，进入容器执行redis-cli：

docker exec -it myredis redis-cli

容器外部连接，关键在端口映射。启动容器时做了-p 6379:6379映射，宿主机上就可以直接redis-cli -h 127.0.0.1 -p 6379。主从部署时，从节点的容器端口要映射到宿主机不同端口，比如主节点映射 6379，从节点映射 6380，这样两边都能从外部访问。

Docker 环境里还有一个常见坑：容器内的 Redis 配置文件里bind如果写的是127.0.0.1，那即使端口映射出来了，外部依然连不上，因为 Redis 在容器内部只监听了回环地址。解决方法是把bind改成0.0.0.0或者删掉默认的 bind 配置，同时一定要设置密码。这个坑我在调试 Docker 主从时踩过一次，现象是“宿主机能 ping 通容器 IP，但 redis-cli 就是连接不到”，原因是配置文件的 bind 没改。

排查 Docker 部署的问题，优先在宿主机上执行：

# 看端口映射是否生效 docker ps # 看容器日志 docker logs myredis # 进入容器手动执行命令 docker exec -it myredis redis-cli ping

这套组合基本上能定位九成的问题。

最后再分享一点我的使用体会

Redis 服务端和客户端命令学起来不难，难的是遇到问题时的排查思路——连接不上，是网络问题还是认证问题？内存报警，是直接加内存还是换淘汰策略？命令执行卡住，是不是触发了KEYS、MONITOR这些阻塞型操作？这些判断能力靠的是对命令底层原理的理解，而不只是记住语法。我自己最开始也是靠可视化工具撑着，后来被生产环境逼着回到命令行，反复踩了几次坑之后，才真正明白redis-cli里那些平时不起眼的参数，在关键时刻能救人一命。如果你刚接触 Redis，我建议把这篇文章里出现的常用命令在本地环境敲一遍，尤其是INFO、SCAN、EXPIRE、CONFIG GET这一组，它们是你以后排查问题的主力工具。基础越扎实，后面学分布式锁、缓存穿透、主从复制这些进阶内容时就越轻松。