永远雪山搞后端的，谁没在深更半夜被数据库慢查询叫醒过？我第一次被Redis圈粉，就是因为一次缓存穿透把MySQL打挂的线上事故。当时满脑子只有一个念头：为什么我不能在最前面加一层又便宜又快的东西挡住请求。后来才发现，这个“东西”就是Redis。
Redis这个数据库，诞生已经十几年了，但直到今天，它仍然是后端技术栈里最不可缺少的一个组件。你要做高并发、缓存、分布式锁、消息队列、排行榜、限流，几乎都会想到它。不管你是准备面试、做架构设计，还是在维护线上系统，理解Redis的优势和特点，都能让你少走很多弯路。这篇文章不打算按官方文档罗列功能，而是从我对Redis的理解出发，结合线上实战踩过的坑，把它真正的价值拆开讲清楚。
1. Redis到底解决了什么问题：先从一次缓存事故说起
1.1 缓存穿透、击穿、雪崩：Redis的救火现场
那次线上事故的起因，其实特别简单。前端页面搞了一个活动，用户进来先查商品详情，我一开始没做缓存，所有流量直接打MySQL。刚开始数据量小，数据库还能扛，结果活动一上线，几十万的并发进来，数据库连接池瞬间被打满，CPU飙到90%多，整个服务直接不可用。
后来我加了一层Redis做缓存，把商品详情序列化后丢进去，读请求先查Redis，命中就直接返回，没命中再查数据库并回填缓存。这个改动上线后，数据库的QPS从几万掉到了几百，系统平稳跑了好几个月。也是从那时候起，我才真正理解缓存穿透、击穿、雪崩这三个问题的严重性：
- 穿透：查询一个根本不存在的数据。缓存里没有，数据库里也没有，每次请求都落到DB。攻击者只要拿一个不存在的ID循环刷，就能把数据库打挂。解决办法是缓存空值，或者用布隆过滤器在缓存前面挡一层。布隆过滤器用Redis的bitmap就能实现，几十万数据也就几十KB内存。
- 击穿：某个热点key在过期瞬间，大量请求同时打到数据库。这个通常发生在秒杀、热点新闻场景。解决办法是互斥锁，只放一个线程去重建缓存，其他线程等待；或者用逻辑过期的方式，后台异步刷新。
- 雪崩：大量key在同一时间过期，或者Redis整体宕机，所有流量直接涌向数据库。解决办法是给过期时间加随机值，避免集体失效，同时后端做降级限流，Redis层面做好持久化和集群高可用。
这三个问题，几乎是所有缓存系统都会遇到的经典场景。Redis之所以能成为救火队员，是因为它够快、够稳、支持的数据结构够丰富，能灵活应对各种缓存策略。
1.2 Redis不是简单的“缓存数据库”
很多初学者把Redis理解成一个“把数据放到内存里的Map”，这个说法没错，但格局小了。Redis真正的定位，是一个基于内存的、支持丰富数据结构的、具备持久化和分布式能力的NoSQL存储系统。
它和MySQL最大的区别在于：MySQL擅长复杂关系查询、事务、报表统计，而Redis擅长的是低延迟读写和对数据结构的原子操作。你做不了“SELECT ... JOIN ... WHERE ...”，但你可以对一个Set做交集、并集、差集，对ZSet做范围查询和排名，对字符串做原子自增。这些操作在MySQL里要写好几条SQL、加好几把锁才能搞定，在Redis里就是一条命令的事。
它也经常被拿来和消息队列、搜索引擎、布隆过滤器这些专用组件对比。我的体会是，Redis更像一把瑞士军刀，它不是一个领域的专家，但几乎每个领域都能插一脚。在中小型项目里，你甚至可以用Redis同时承担缓存、分布式锁、轻量消息队列、Session共享、排行榜、限流器等多个角色，省下好几套中间件的运维成本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心优势拆解：三个维度看Redis的快
2.1 内存存储与数据结构的化学反应
Redis快的第一个原因，是数据存在内存里。内存的访问延迟是纳秒级别，磁盘是毫秒级别，差了三个数量级以上。同样是读一个key，MySQL要先走B+树索引、读磁盘页、解析行数据，Redis直接在内核态网络模块收到命令后从哈希表里取，这个差距是物理层面的，优化代码解决不了。
但光有内存还不够，Redis能保持速度快，还在于它针对每种场景设计了专门的数据结构。比如ZSet，底层用的是跳表加哈希表，跳表实现有序性，哈希表实现O(1)查找，所以你能同时做到“快速取分数”和“按分数范围遍历”。如果让MySQL来干这活，你至少得维护一个带索引的表，每次查询还要走一次SQL解析和网络往返。
Redis的字符串类型底层叫SDS，也就是简单动态字符串，它不光存了字符数组，还存了长度和空闲空间。这样做的好处是获取字符串长度是O(1)，不需要遍历；追加字符串时如果空间够就原地修改，减少内存分配次数。这些细节，都是Redis在单线程环境下依然能扛住高并发的底层原因。
2.2 单线程事件循环，以及IO多路复用
Redis最常被人讨论的设计，就是单线程。很多新手会问：单线程怎么能支撑十万级别的QPS？答案在于，Redis的瓶颈几乎从来不在CPU，而在网络IO和内存。它把所有的命令执行都放在一个线程里，用事件循环的方式处理海量连接，这就是IO多路复用技术，在Linux上就是epoll。
单线程带来的最大好处，是不存在并发竞争。你不需要加锁，不需要考虑线程切换的开销，也不用担心多个线程同时修改一个数据结构导致数据错乱。Redis官方给出的数据是，单实例QPS轻松达到10万以上，这在绝大多数业务场景里已经完全够用了。
不过在Redis 6.0版本之后，官方引入了多线程IO，允许用多个线程处理网络读写，但命令的真正执行仍然在单线程中完成。这个设计非常巧妙：网络IO是耗时的，可以并行；数据操作是敏感的，必须串行。既要吃满多核CPU的网络能力，又要保证Redis命令的原子性和一致性，两者都兼顾到了。
2.3 快是有代价的：Redis的取舍
Redis快，但不是没有代价。它最明显的劣势是内存成本高，同样一份数据，存在Redis里比存在MySQL里贵得多。所以Redis不能当成万能存储来用，你要控制每个key的大小，设置maxmemory限制内存上限，并配置淘汰策略。常见的淘汰策略有noeviction（不淘汰，写不进新数据）、allkeys-lru（按LRU淘汰所有key）、volatile-ttl（淘汰即将过期的key）等，线上一般用allkeys-lru，或者根据业务特点选择allkeys-lfu。
其次，单线程虽然避免了很多问题，但也意味着一个慢命令会阻塞所有后续命令。比如在几千万key的实例上执行KEYS命令，整个Redis会卡住好几秒，线上请求全部超时。这个坑我踩过不止一次，后面第8章会单独讲SCAN的用法。
再有一个容易被忽略的点，Redis的快是相对的。如果你把一个大对象当成value存进去，每次写入都要序列化和内存拷贝，读取时又要反序列化，性能会急剧下降。所以Redis官方文档里反复强调：不要让单个key的value过大，尽量拆分成多个小key，或者用hash结构。这也是为什么很多Redis规范里会写上“单个key的value不要超过10KB”这样的硬性要求。
3. 数据类型不是摆设：从业务场景理解Redis数据结构
3.1 字符串和哈希：最常用也最容易被用反
字符串类型是Redis最基础的类型，能存字符串、数字、二进制数据，最大512MB。它的应用场景太广了：页面缓存、接口返回值缓存、计数器、分布式ID、Session共享，都能用字符串搞定。常用的命令有SET、GET、MSET、MGET、INCR、DECR、SETNX、SETEX等。
这里有个细节，INCR自带原子性。你要做一个点赞计数、库存扣减、限流计数，直接INCR就行，不需要先GET再SET。因为单线程模型下，Redis的INCR天然就是线程安全的，多个客户端并发调用不会出现超卖或者计数丢失。
哈希类型存储的是字段和值的映射，相当于一个对象。比如用户信息，你可以用HSET user:1001 name "zhangsan" age 20，这样每次更新只改一个字段，不需要把整个对象取出来反序列化再写回去。在存储小对象时，哈希还有一个优势：当字段数量少的时候，底层使用紧凑编码，比字符串序列化后存储省内存。很多公司做缓存时都建议用哈希存对象，而不是用JSON字符串，就是这个原因。
关于字符串和哈希的选择，我的个人建议是：如果数据是完整的、不常修改的文本内容（比如接口返回的HTML片段），用字符串；如果数据是一个结构化对象，经常要改其中某个字段，用哈希。
3.2 列表、集合、有序集合：队列、去重与排行榜
列表类型底层是双向链表或者压缩列表，支持从两端push/pop，天然适合做消息队列的雏形。用LPUSH加BRPOP，可以实现一个阻塞队列，消费端没有消息时会阻塞等待，而不是空转轮询。它还适合做最新列表类场景，比如用户的时间线，LPUSH新消息，LRANGE取前20条，非常快。
集合类型是无序去重的，支持SADD、SREM、SISMEMBER，还支持SINTER、SUNION、SDIFF这些集合运算。做社交场景时，A用户的好友和B用户的好友取交集，就能算出共同好友；用集合存标签，按标签筛选用户，一条命令就出来了。抽奖场景也很合适，SADD把用户ID丢进去，SPOP随机弹出中奖者，保证不重复。
有序集合ZSet是Redis里我个人最喜欢的一个类型，它在Set的基础上给每个元素加了一个score。ZADD添加元素，ZRANGE按分数从小到大取列表，ZREVRANGE按分数从大到小取列表，ZINCRBY给指定元素加分。排行榜、热门文章列表、延时队列（用score存执行时间戳）都能用它实现。它的底层是跳表，查找和插入都是O(logN)，性能非常稳定。
3.3 加密款类型：bitmap、HyperLogLog与GEO
除了五种基本类型，Redis还有几个容易被忽略、但实际很实用的特殊类型。
bitmap本质是字符串的位操作，一个位就是一个0或1，可以玩出很多花样。比如统计用户连续签到天数，每位代表一天的签到状态；统计日活用户，每个用户ID对应一个位，置1就代表当天活跃；用它可以实现一个小型布隆过滤器，判断某个ID是否存在，虽然可能有误判，但绝大多数场景能接受。
HyperLogLog是用来做基数统计的，一句话就是“用很省的内存估算去重数量”。传统方案存几千万个UVID要占用几百MB内存，用HyperLogLog只需要12KB，误差在0.81%左右。做UV统计、PV去重这类不需要精确值的场景，它是首选。
GEO类型用来存储经纬度坐标，支持计算两地距离、查找附近的人。底层实现是ZSet加GeoHash编码，你可以用GEOADD添加门店位置，用GEORADIUS查询某个坐标周围N公里内的门店。做外卖、打车、附近门店这类LBS场景时，不需要自己写空间索引，Redis直接就能搞定。
3.4 新版本带来的特性演进
Redis的版本演进一直很活跃。Redis 6.0引入了ACL权限控制、多线程IO、RESP3协议、客户端缓存等能力，在安全性和性能上都有明显提升。Redis 7.0则进一步优化了AOF的日志格式，把多个小文件合并成单一文件，同时用listpack替代了部分ziplist，提升了内存使用效率。
关于新特性，这几年业界讨论比较多的还有Redis 8在向量检索方向上的探索。随着AI应用普及，向量数据库成了热点，Redis也计划支持向量搜索能力，让Redis不仅能做缓存，还能做相似度检索。虽然现阶段还不建议把核心向量业务完全押在Redis上，但它在这个方向上的尝试，确实让Redis的生命力又强了不少。
4. 持久化与可靠性：快是底线，不丢数据才是护城河
4.1 RDB和AOF，哪个更靠谱
很多人用Redis只是当缓存，认为丢了也没关系，重启后从数据库再回填就行。但一旦Redis承担了计数、排行榜、分布式锁等有状态业务，持久化就必须认真对待。Redis提供了两种持久化方案：RDB和AOF。
RDB是快照，它把某一时刻的完整数据写入一个二进制文件。触发方式有手动触发（SAVE/BGSAVE）和自动触发（按save配置，比如900秒内有一个key变化就触发一次）。RDB的好处是文件紧凑、恢复速度快；缺点是快照之间的数据会丢失，比如900秒才存一次，这期间宕机就丢数据。
AOF是追加写日志，每次写命令都会记录到AOF文件里。它的可靠性取决于fsync策略：always表示每次命令都同步磁盘，最安全但慢；everysec表示每秒同步一次，最多丢失一秒数据；no表示交给操作系统刷盘，性能最好但可能丢更多数据。AOF的优点是可靠性高、可读性好，缺点是文件会越来越大，恢复时逐条执行命令比加载RDB慢很多。
4.2 混合持久化：取舍之后的最优解
好在Redis 4.0之后提供了混合持久化方案：AOF文件可以先用RDB格式做一份完整的基线快照，再记录后续的增量命令。这样重启恢复时，先快速加载RDB部分，再回放少量增量命令，既兼顾了恢复速度，又保证了数据可靠性。我现在的线上配置都是aof-use-rdb-preamble yes，这个组合实测下来比较稳。
还有一个容易忽略的点，就是fork子进程写持久化文件时的COW机制。Redis在执行BGSAVE或AOF重写时，会fork一个子进程，子进程负责写文件，父进程继续处理请求。这个fork过程本身是很快的，但如果实例占用内存特别大，fork会复制页表，可能造成短暂的卡顿。所以大实例（比如超过10GB）要尽量避免频繁触发RDB快照，最好把持久化时间错开业务高峰。
无论选择哪种持久化，都建议给持久化文件做异地备份，比如每天定时把dump.rdb或AOF文件打包上传到对象存储。这样即使机器磁盘损坏，也能从备份里恢复数据，这是最后一道保险。
4.3 主从复制、哨兵与故障转移
持久化解决的是进程崩溃后的数据恢复，但机器宕机、机房断电这种级别的问题，还得靠主从复制和哨兵来解决。
主从复制模式下，一个主节点负责写请求，多个从节点同步主节点的数据，负责读请求。这样能减轻主节点的读压力，也能在主节点挂掉后让从节点顶上。复制过程分为全量同步和增量同步：从节点第一次连接主节点时，主节点生成RDB快照发给从节点，之后通过repl_backlog缓冲区同步增量命令。主从之间会有短暂延迟，如果业务对一致性要求很高，要注意这个延迟可能会读到旧数据。
哨兵Sentinel是负责监控和自动故障转移的组件。它通过心跳检测主节点是否存活，当主节点挂了，哨兵会从从节点中选出一个提升为新主节点，并通知客户端更新连接地址。部署哨兵时至少要有3个实例，形成奇数，防止脑裂。主从加哨兵的架构，是中小型项目里最常见的Redis高可用方案，配置不复杂，但能解决90%的可用性问题。
5. 从单机到集群：Redis分布式能力的演进
5.1 主从+哨兵架构的部署要点
我部署过不少Redis主从环境，第一次用Docker起主从时也踩过坑，比如主节点设置了密码，从节点没配masterauth，结果复制一直失败，日志里全是“NOAUTH Authentication required”。所以记住一点：主从配置了requirepass，从节点必须同时配置masterauth，不然无法完成认证。
主从架构还有一个容易被忽略的点，就是从节点默认是只读的，你如果想用从节点做一些缓存清理或者临时写入，需要显式设置replica-read-only no。但正常情况下不建议这么做，保持从节点只读，才能保证主从数据一致。
关于客户端连接，主从切换后客户端的连接地址会变，所以不能让业务方硬编码Redis实例地址。要么用哨兵的地址，客户端通过Sentinel获取当前主节点；要么在前端加一层代理，比如用HAProxy或者nginx的stream模块做四层TCP转发，VIP漂移对业务方透明。nginx四层代理转发Redis流量是可行的，把stream配置好，指向后端的Redis主节点，切换时只需改代理的上游配置。要注意的是，Redis连接是长连接，代理要配置好空闲超时和连接复用，否则高并发下容易把连接数打满。
5.2 Cluster分片与槽位机制
主从加哨兵虽然解决了高可用，但主节点只有一份数据，写能力扩展不了。当单个Redis实例的内存和写入吞吐成为瓶颈时，就得考虑Redis Cluster集群模式。
Cluster模式采用无中心架构，数据按照key的CRC16哈希值取模16384，映射到16384个槽位上，每个主节点负责一部分槽位。当你往集群里写数据时，客户端计算key属于哪个槽，如果槽不在当前连接节点上，节点会返回MOVED重定向，客户端再跳到正确的节点执行命令。这也是Cluster模式对客户端要求比较高的原因，客户端必须实现集群协议，支持自动路由。
Cluster集群至少需要3个主节点，生产环境通常会配3主3从，每个主节点带一个从节点，主节点挂了从节点顶上。槽位可以手动分配，也可以用redis-cli --cluster create自动分配，后者会帮你把16384个槽均匀分到3个主节点上。
在Cluster模式下，多key操作要特别注意。比如MSET、事务、Lua脚本，如果操作的key哈希槽不一致，会直接报错。解决办法是用hash tag，比如把key写成{user100}.profile和{user100}.orders，花括号里的内容参与哈希计算，这样两个key会落到同一个槽位，就能进行多key操作了。
5.3 集群间数据同步与迁移的思路
有朋友在迁移场景里问过：集群1的数据怎么同步到集群2？这个问题在系统改造、机房搬迁、实例规格升级时经常遇到。我目前用过比较好的方案是借助开源的数据同步工具做全量加增量迁移，比如常见的redis-shake、redis-port等，先把源集群的全量RDB拉取到目标集群，再持续同步增量写入，最后在低峰期切换业务流量。
整个迁移过程要注意几点：第一，目标集群的槽位分配是否合理，直接影响数据分布是否均匀；第二，迁移期间要关注增量同步的延迟，如果延迟一直追不上，说明业务写入压力大，需要错峰执行；第三，切换之前先在目标集群做数据校验，用脚本抽查一部分key的value是否一致，别等切完才发现数据对不上。RDB导入这种方式适合做离线冷备恢复，但不适合持续在线迁移，因为你导入完成到切换之间，源集群又会有新数据写入。
如果是两个独立的Redis集群间做实时同步，工具方案一般都需要额外部署一个同步进程，它伪装成源集群的从节点，实时接收源集群的增量RDB和命令传播，再写入目标集群。这种部署现在工具做得很成熟了，几分钟就能搭起来，但一定要在测试环境先演练，把流程跑通再上生产。
6. 典型场景实战：缓存、分布式锁、消息队列与分页优化
6.1 缓存治理，以及分页慢查询的优化
缓存治理的核心，就是围绕刚才说的穿透、击穿、雪崩做防御。我的标准做法是：查询请求先打Redis，没命中再打MySQL，成功后回填缓存，并设置一个随机过期时间；对不存在的key也缓存一个空值，TTL设置短一些，比如30秒；对热点key，在缓存里加一个逻辑过期时间，后台用一个异步线程定期刷新，避免瞬间击穿。
这里分享一个分页查询慢的优化思路。MySQL分页越往后越慢，比如LIMIT 100000, 10，即使有索引，也要扫过10万行数据再丢弃，非常耗时。我做过一个列表页的优化，做法是：把每页对应的ID列表存入Redis的ZSet，score用排序字段（比如创建时间），先用ZREVRANGE从有序集合里取出当前页需要的ID，再用MGET批量获取这10个ID对应的缓存数据，如果缓存缺失再回源数据库。这样排序和越界判断都在Redis里完成，数据库只需要做等值查询，性能提升特别明显。
不过要注意，这种方案只适合排序条件固定的场景。如果用户能随意切换排序字段，缓存命中率会急剧下降。我的建议是，只对默认排序和默认筛选条件做缓存，其他条件走数据库，别想着把所有维度都缓存起来，内存扛不住，缓存维护成本也太高。
6.2 分布式锁：SET NX PX的正确写法和常见坑
Redis做分布式锁，是面试必问、线上必用的一个场景。正确写法其实很简单：SET key value NX PX 30000，key是锁的标识，value是一个唯一标识（比如UUID），NX表示只有key不存在时才设置成功，PX表示锁的自动过期时间，防止持有锁的线程宕机导致死锁。
这里有个常见的坑，就是很多人会写成两步：先SETNX，再EXPIRE设置过期时间。这两个操作不是原子的，如果SETNX之后、EXPIRE之前程序崩溃了，锁永远不会释放，其他线程会一直阻塞。所以必须用一条原子命令SET key value NX PX。
释放锁时也不能简单DEL。如果线程A持锁超时，锁自动过期了，线程B获取了同一把锁，然后A执行DEL把B的锁给删了，这就出问题了。正确的释放逻辑是：先用Lua脚本比较value是不是自己的标识，相同才删除。Lua脚本保证了“判断加删除”是原子的，Redis单线程执行Lua，不会中途插入其他命令。
关于分布式锁的可靠性，要记住一个事实：Redis主从切换可能导致锁丢失。比如线程A在主节点上拿到了锁，还没同步到从节点，主节点挂了，从节点晋升为主，此时锁不存在，线程B也能拿到同一把锁。如果是严格互斥的资源，这种极端情况不能接受。业界有RedLock方案试图解决，但实现复杂，争议也大。我的建议是，能不依赖Redis分布式锁就尽量不用，一定要用的话，业务上要加幂等和唯一约束做兜底。
6.3 Redis当消息队列：Stream与broker/backend双存储
Redis能不能当消息队列来用？答案是可以，但要分场景。Pub/Sub模式不持久化消息，消费者不在线消息就丢了，只适合实时通知、广播这类低频场景。List加BRPOP能实现一个可靠的简单队列，但消费确认、消息重试都需要自己实现。
如果你的消息量不是特别大，又不想引入RabbitMQ或Kafka，Redis 5.0之后引入的Stream类型值得试试。Stream提供了消息ID、消费者组、消费确认（ACK）、消息持久化能力，基本实现了轻量MQ的完整功能。XADD添加消息，XGROUP创建消费者组，XREADGROUP让消费者从组里读消息，读完XACK确认，未确认的消息留在PEL（待处理列表）里，可以重复消费或重新入队。
还有一组合法玩法，就是把Redis同时作为异步任务的broker和backend。比如Python的Celery框架，配置了broker_url和result_backend，两者都可以指向Redis，broker用0号数据库存任务队列，backend用1号数据库存任务执行结果。这样一套Redis实例就能撑起整个异步任务体系，非常省事。注意两个库要分开，别混在一起，不然任务消息和结果数据会互相干扰。
Redis做消息队列的短板在于，消息堆积时内存占用会线性上涨，不像Kafka可以靠磁盘缓存大幅缓冲；消息的投递语义也不像专业MQ那么细。所以我的原则是小流量、低延迟、数据不敏感的任务用Redis，核心业务消息队列还是交给专业组件更稳。
7. 工具链与部署经验：安装、可视化工具、Docker
7.1 Windows和Linux下安装Redis的坑
Redis官方其实不支持Windows，官网下载页面里只提供Linux和macOS版本。但开发环境的同事很多用的是Windows，网上能找到一些社区移植版本，比如tporadowski的Redis for Windows，可以像普通软件一样解压运行，也可以用redis-server.exe --service-install注册成Windows服务。
我个人的建议是，Windows开发机上优先用WSL2装一个Linux环境跑Redis，因为版本更新、兼容性最好，而且和生产环境行为一致，排查问题时不会因为“Windows版Redis”和“Linux版Redis”行为差异而踩坑。Windows下如果只做测试，直接下载移植版也够用，但别在生产环境用Windows跑Redis，内存管理和网络性能都和Linux差很多。
Linux安装Redis的方式很多，apt install redis-server、yum install redis，或者去官网下载源码编译安装。源码安装要注意把redis-benchmark、redis-sentinel这些配套工具也装上，还要把配置里的daemonize yes打开，或者用systemd管理服务。无论哪种方式，装完第一步一定是改密码、绑定内网IP、关闭protected-mode。默认配置下Redis是没有任何访问控制的，暴露到公网等于直接把数据送人，这个问题每年都有无数人踩。
7.2 Docker部署Redis主从，一条命令搞定
现在用Docker部署Redis主从，比直接装二进制省事太多了。我用一个docker-compose文件就能把一主一从跑起来：
yaml复制version: "3"
services:
redis-master:
image: redis:7
container_name: redis-master
ports:
- "6379:6379"
command: redis-server --requirepass 123456 --appendonly yes
redis-slave:
image: redis:7
container_name: redis-slave
ports:
- "6380:6379"
command: redis-server --requirepass 123456 --masterauth 123456 --replicaof redis-master 6379 --appendonly yes
depends_on:
- redis-master
启动后进入从节点容器，执行INFO replication，能看到role:slave，master_host指向redis-master，如果显示master_link_status:up，说明主从复制建立成功。这里有个容易踩的坑：replicaof后面的主机名是容器内的服务名，不是localhost，因为两个容器在同一个Docker网络里，必须用容器名互访。
生产环境用Docker部署Redis，一定要把数据目录挂载出来，比如加一行volumes: - ./data:/data，然后把持久化文件放在挂载目录里。否则容器重建，数据直接归零。配置也要用挂载conf文件的方式，方便维护，不建议在command里写一大串参数，改起来太麻烦。
7.3 可视化工具选型：RDM、Another Redis Desktop Manager与Redis Insight
Redis官方命令行客户端redis-cli功能很强大，但日常调试、查看数据、监控状态，可视化工具能省很多时间。目前主流的三个工具我都有实际使用经验：
- Redis Desktop Manager：老牌工具，界面好看，但从0.9.x版本之后免费的社区版停止更新了，新版本是付费订阅制。很多网站在老版本的下载链接里打包了推广内容，下载时要小心校验文件MD5。
- Another Redis Desktop Manager：免费开源，功能很全，支持Windows、macOS、Linux，key树形展示、搜索、JSON格式化、命令行都有。如果不想付费，优先推荐这个，我团队里用它的最多。
- Redis Insight：Redis官方推出的免费可视化工具，支持数据浏览、命令分析、内存分析、慢日志查看，还能直接看到Cluster拓扑。官方出品的好处是和新版本特性同步最快，比如Redis 8新增的向量检索能力，Redis Insight会第一时间支持。
如果你只是临时连一下远程Redis，用Redis Insight最稳，省得折腾下载源的麻烦；如果长期开发调试，Another Redis Desktop Manager体验更顺手。不管用哪个，都建议别在生产环境用可视化工具执行删除操作，手一抖误删一个key，没有后悔药。
8. 常见问题与排查技巧实录
8.1 KEYS通配符为什么会卡死，SCAN怎么用
热词里有个“keys ekyc_pic_*”，这种用KEYS做通配符匹配的写法，是生产环境的定时炸弹。KEYS命令会阻塞Redis主线程，遍历整个键空间，如果你这个实例有几千万个key，一执行就是几秒钟的阻塞，所有读写请求全部排队。线上出现大面积超时，有一半的锅是这个。
正确的做法是用SCAN命令做增量遍历。SCAN每次返回一批key和一个游标，你拿着游标继续迭代，直到游标回到0。比如：
bash复制SCAN 0 MATCH ekyc_pic_* COUNT 1000
SCAN的优势是每次只遍历一小部分槽位，不会阻塞主线程，适合生产环境。注意SCAN的结果并不保证每次都能命中全部匹配的key，因为遍历过程中key可能被修改或删除。如果你要做的是一次性清理操作，比如删掉某个前缀的所有key，可以配合SCAN拿到key列表后，用UNLINK命令异步删除，千万别用DEL删大key，DEL是同步阻塞的。UNLINK会先把key从键空间摘除，再在后台线程异步释放内存，即使key很大会阻塞也只在很小的窗口内。
8.2 查看key、监控内存与定位慢查询的常用命令
排查Redis问题，我常用的命令分三组。
第一组是查看key的值和类型。先执行TYPE key确定类型，然后根据类型执行对应的查询命令：字符串用GET，哈希用HGETALL或者HGET key field，列表用LRANGE key 0 -1，集合用SMEMBERS，有序集合用ZRANGE key 0 -1 WITHSCORES，同时想看过期时间用TTL key。这一套流程能快速定位“这个key下面存了什么”。
第二组是监控实例状态。INFO是最常用的命令，INFO memory查看内存分配和峰值，INFO stats查看命中率和key数量，INFO replication查看主从同步状态。内存不够时看used_memory_human和maxmemory_human，命中率低说明缓存设计有问题，要考虑增加缓存命中或者调整过期策略。
第三组是定位问题，慢日志。SLOWLOG GET 10能列出最近10条执行时间超阈值的命令，默认阈值是10毫秒，可以用CONFIG SET slowlog-log-slower-than 10000调整。每次看到线上超时，第一步不是看应用日志，而是先查Redis的slowlog，看是不是有HGETALL大key、KEYS、SORT这类慢命令在阻塞。另外MONITOR命令可以实时打印所有请求，但生产环境慎用，它会极大消耗性能，相当于把Redis的每一条操作都记录了下来，压测环境还好，线上开了会加速宕机。
8.3 踩坑多年总结的Redis避坑清单
这些年用Redis，踩过的坑远不止前面的那些。最后整理一份避坑清单，每条都是真实教训：
- 给所有key设置合理的过期时间，不要让它永远占着内存，除非它是真正的永久数据。
- 设置maxmemory并选好淘汰策略，避免数据写满内存之后Redis直接拒绝写入，导致上层业务报错。
- 单个value别超过10KB，超过的拆分成多个key或者用hash，避免大key阻塞。
- 禁止在循环里频繁操作Redis，尽量用pipeline批量发送命令，能显著降低RTT。
- 使用连接池，不要每次请求都新建连接，连接创建和销毁的开销远比你想象的大。
- 前缀命名规范很重要，比如user:1001:profile，同一类业务key有固定前缀，便于统计、清理和定位。
- 不要直接把Redis当数据库，Redis的数据最终还是要能从MySQL等持久化存储重建，它只是一个加速层。
- 监控Redis的CPU、内存、连接数和命中率，数据超过告警阈值要及时处理，不要在出问题之后才想起来看监控。
- Redis 6.0以上要用ACL做权限控制，给不同业务线分不同账号，避免一个业务线清空整个Redis。
- 主从切换后，业务端要做好重连逻辑，不能只认初始的IP，要能通过哨兵或者代理自动发现新主节点。
踩过这么多坑之后，我的体会是，Redis用得好不好，往往不在于你掌握了多少冷门命令，而在于你对它的内存模型、单线程模型和持久化机制有没有敬畏心。把每个key都当成一个需要认真对待的数据单元，把每条命令的执行代价都考虑清楚，线上Redis基本就不会给你惹麻烦。真正理解它之后你会发现，Redis的优势和特点，从来不只是快那么简单。