不少人第一次接触 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 yesdaemonize直译是“守护化”意思就是把进程变成守护进程脱离当前终端在后台静默运行。启动后它会返回一个 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 或 RDBkill -9会让进程来不及做清理和持久化收尾极端情况下可能丢数据或者留下不完整的 AOF 文件。正确做法是用客户端命令优雅地关闭redis-cli shutdown如果服务端设置了密码还要加上认证参数redis-cli -a yourpassword shutdownSHUTDOWN命令的执行逻辑是先停止接收新的请求然后根据配置决定是否执行持久化操作最后再退出进程。整个过程是“有序撤退”而不是“突然断电”。如果你执行完 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 100KEYS会遍历所有 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:02List 类型是双向链表适合做消息队列、时间线等场景。常用命令是LPUSH、RPUSH、LPOP、RPOP和LRANGE。做简单的先进先出队列就是左边进、右边出LPUSH queue:task job1 RPOP queue:taskSet 类型是无序集合天然支持去重和集合运算适合做标签系统、共同好友这类场景。SADD添加成员SREM删除成员SINTER求交集SUNION求并集一行命令就能完成分组统计。ZSet 类型在 Set 的基础上给每个成员附加了分数按分数排序适合做排行榜。命令模式是ZADD key score member查询用ZRANGE或ZREVRANGE。做“过去 24 小时热搜榜”这类需求ZSet 几乎是首选因为它既能存储数据又天然有序排序逻辑由 Redis 内部完成。五种数据类型放在一张表里看更清楚类型底层结构典型命令典型场景String动态字符串SET / GET / INCR缓存、计数器、分布式锁Hash哈希表HSET / HGET / HGETALL对象存储List双向链表LPUSH / RPUSH / LPOP消息队列、时间线Set哈希集合SADD / SINTER / SUNION去重、集合运算ZSet跳表哈希表ZADD / ZRANGE / ZREVRANGE排行榜、延时队列每个类型的命令都不止这几个但把这批常用命令吃透日常开发已经能覆盖七成以上的场景了。我建议学习顺序是先用 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 这类结构化数据一屏滚动下来眼睛都花了。可视化客户端就是来解决这个问题的这些年我用过不少比较有代表性的几款可以给个参考工具跨平台是否免费特点Redis Desktop Manager是部分开源老牌工具界面直观社区资料多Another Redis Desktop Manager是免费开源RDM 的社区维护版本性能不错RedisInsight是免费Redis 官方出品的可视化工具功能迭代快命令行 redis-cli是自带无图形界面但最灵活、最基础可视化客户端的连接配置本质上和命令行连接参数是一一对应的。填 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-lruallkeys-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-clidocker 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这一组它们是你以后排查问题的主力工具。基础越扎实后面学分布式锁、缓存穿透、主从复制这些进阶内容时就越轻松。