Redis 是后端开发里出现频率最高的中间件之一。无论是缓存、分布式锁、排行榜、消息队列还是面试题里常见的缓存穿透、缓存雪崩、缓存一致性话题最后都会落到 Redis 的数据结构、内存模型和高可用方案上。很多人第一次接触 Redis 时只把它当成一个“快一点的键值数据库”等并发量上来、主节点宕机、数据恢复不了才发现 Redis 的完整价值是把性能、数据结构和可靠性组合成了一整套能落地的中间件能力。下面按三个核心秘密展开第一个是内存存储与单线程事件循环解释为什么它快第二个是五种基本数据结构解释为什么它能从缓存升级成工具集第三个是持久化、主从、哨兵和集群解释为什么它能上生产环境。读完后你会得到一条从安装、配置、命令验证、使用场景到生产排错的完整路径。1. 先用使用场景理解 Redis它解决的从来不只是缓存问题1.1 缓存是最先被感知到的 Redis 价值早期 Web 应用最常见的瓶颈是数据库。同一个热点数据被反复查询网络带宽和数据库连接都被浪费。商品详情页、用户信息、配置数据在流量高峰时都是典型的“读多写少”场景。如果每次请求都直接访问数据库表行多、SQL 复杂时响应时间就会明显上升。Redis 作为缓存层放在数据库前面第一次读取时落到数据库后续读取直接走 Redis。最简单的方式是redis-cli SET user:info:1001 {\name\:\zhangsan\} EX 300 redis-cli GET user:info:1001EX 300表示 300 秒后自动过期避免缓存数据长期不更新。这样数据库的压力从“每个请求都打”降为“缓存未命中才打”。为什么不用应用本地内存做缓存这个问题很关键。应用本地缓存比如 JVM 里的 HashMap 或 Caffeine每个应用节点各自存一份数据不好同步。用户第一次请求落在 A 节点缓存写进 A 的内存第二次请求被负载均衡到 B 节点B 没有缓存又回源数据库。多实例部署时本地缓存的命中率并不稳定。Redis 是独立进程所有应用节点共享同一份缓存数据所以更适合做分布式场景下的统一缓存。1.2 从缓存到中间件为什么后面三个秘密才是关键如果 Redis 只能做缓存它不会像今天这样普及。它的竞争力在于同一个服务里还能处理很多其他中间件才能完成的场景。String 的INCR可以做访问计数、限流计数List 的LPUSH配合BRPOP可以做简单任务队列Set 可以做去重、抽奖、共同关注ZSet 可以做排行榜Redis Stream 可以做消息队列SET NX EX可以实现分布式锁多个节点共享 Session 时也可以把 Session 数据放进 Redis。这些能力不需要引入多个中间件而是一套命令、一套客户端、一套部署方式。Redis 的学习成本相对低业务接入简单复用价值高这是它“火”的第二个层面从单一缓存工具变成了通用数据工具。1.3 读这篇文章前需要准备什么这篇文章不需要你先写一整个项目。需要的基础条件很简单能打开终端会执行最基本的 Linux 命令。本机能安装 Redis或者能使用 Docker 运行 Redis 容器。有一定后端开发经验知道数据库查询慢、缓存、并发是什么概念。文章里的命令示例基于 Redis 7 环境验证。如果你的版本不同命令主体不变但个别默认配置或参数可能需要调整。落地到项目前先确认自己的 Redis 版本和部署方式不要照抄所有配置。2. 核心秘密一内存数据模型与单线程 IO 多路复用2.1 内存存储为什么快数据库查询慢慢在磁盘访问。机械硬盘需要寻道SSD 虽然快但随机读写和内存相比仍然有数量级差距。Redis 把数据存放在内存中读写路径短不需要等待磁盘寻址。即使开启了 RDB 或 AOF 持久化磁盘写入也是异步或批量触发不占用每次查询的关键路径。内存快但不是没有代价。内存价格比磁盘高单台机器内存容量有限。Redis 如果无限制写入最终会耗尽内存导致系统异常。所以 Redis 提供了maxmemory配置和淘汰策略比如allkeys-lru会在内存满时优先淘汰最近最少使用的 key。实际项目中内存规划应该先于功能开发。先用CONFIG GET maxmemory查看当前限制再根据业务预估 key 数量和单个 key 大小。缓存可以淘汰但做分布式锁或消息队列时key 丢失会造成业务影响不能简单套用缓存淘汰策略。2.2 单线程不是性能瓶颈而是一种设计取舍Redis 的核心命令执行是单线程的。很多人第一次听到会疑惑单线程为什么还能快单线程带来的好处非常直接没有锁竞争多个命令之间不会互相等待。没有线程上下文切换开销。命令执行顺序确定单个 key 上不会出现并发写问题。数据结构实现可以做得更简单不需要考虑复杂并发控制。Redis 的快建立在命令本身执行很快的前提上。String GET、SETHash HSETList LPUSH 这些操作大多是 O(1) 或接近 O(1)。如果命令都是 O(N) 的比如KEYS *即使单线程也会卡住这就是后面要讲的坑。需要纠正一个误解Redis 单线程并不代表无法利用多核 CPU。Redis 的性能瓶颈通常在网络读写和内存带宽而不是 CPU 计算。如果一台机器需要更高吞吐可以部署多个 Redis 实例每个实例绑定不同端口应用层做分片不需要在单个实例里强行用多线程。在 Redis 6.0 中引入了 IO 多线程主要用于网络数据的读取和写出。命令解析和执行阶段仍然保持单线程。所以讨论最新版本时说“Redis 完全单线程”并不严谨但核心命令执行模型仍然是单线程的。2.3 事件循环与 IO 多路复用单线程要服务大量客户端必须解决一个核心问题网络 IO 等待不能阻塞其他请求。传统的阻塞式编程中每个连接需要一个线程线程数量上来后上下文切换成本很高。Redis 使用 IO 多路复用机制在 Linux 上主要基于 epoll在 macOS 上基于 kqueue。它可以同时监听大量 socket 文件描述符当某个客户端连接有数据可读、或者可以写入响应时操作系统主动通知 Redis 事件循环。事件循环的工作方式类似注册需要监听的文件描述符。阻塞等待内核通知就绪事件。有事件发生后逐个处理对应连接的数据读取、命令解析、执行和响应写入。回到等待状态。这样一条主循环可以服务成千上万个连接IO 等待阶段不占用 CPU。高并发不是靠多线程堆出来的而是靠事件模型把 CPU 用在真正有请求需要处理的时候。2.4 用 redis-benchmark 验证性能理论讲完最好自己跑一次压测。Redis 自带redis-benchmark工具不用写代码。redis-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 100000 -c 50 -q参数含义参数作用示例-hRedis 地址127.0.0.1-pRedis 端口6379-t测试的命令类型逗号分隔set,get-n请求总数100000-c并发连接数50-q只输出最终结果减少冗余输出无执行后类似输出SET: 87341.37 requests per second GET: 90234.75 requests per second这两行数字表示每秒能处理的请求数。不同机器、不同 Redis 版本、不同数据结构结果差异很大。不要直接背网上看到的数字重要的是掌握验证方法。生产环境做容量评估时建议用业务实际命令和接近真实的 key 分布重新压测而不是只压 set/get。3. 核心秘密二五种数据结构把 Redis 从缓存变成工具集3.1 五种基本结构速览Redis 不只是 value 为字符串的 Map。它提供的五种基本结构各有不同语义很多业务场景可以落到具体结构上。结构典型命令适合场景注意点StringSET GET INCR缓存、计数、限流、分布式 IDINCR 是原子操作适合做自增HashHSET HGET HGETALL对象字段缓存字段多时避免使用 HGETALL 取全部ListLPUSH RPOP BLPOP简单队列、消息列表消费即删除消息不持久SetSADD SISMEMBER SINTER去重、共同关注、抽奖大集合交集计算可能耗时ZSetZADD ZRANGEBYSCORE ZREVRANGE排行榜、延迟队列score 排序依赖浮点数精度String 最常见的是缓存 JSON 字符串和计数器。Hash 适合对象结构比如用户信息不需要像 String 一样每次整体序列化和反序列化。List 的LPUSH从左边写入RPOP从右边取出最适合先入先出的队列。Set 天然去重SISMEMBER可以判断元素是否存在。ZSet 每个成员带一个 score按 score 排序所以排行榜是它的经典场景。3.2 用命令验证常用结构打开终端进入 redis-cli输入下面命令验证redis-cliSET user:login:count 1 INCR user:login:count HSET user:info:1001 name zhangsan age 18 city beijing HGET user:info:1001 name LPUSH queue:task task-1 RPOP queue:task SADD tag:java spring SADD tag:java redis SINTER tag:java ZADD rank:hot 100 article-1 ZADD rank:hot 200 article-2 ZREVRANGE rank:hot 0 -1执行后INCR会把user:login:count从 1 变成 2。Hash 只更新 name 字段时不需要重写整个对象。List 在RPOP后会返回task-1队列里不再保留该元素。Set 的SINTER可以求多个集合的交集但集合很大时会有计算开销。ZSet 的ZREVRANGE rank:hot 0 -1会按分数从高到低返回成员这就是排行榜的核心命令。3.3 数据结构选型里的权衡选结构时不能只看命令简单还要看访问模式。对象数据尽量用 Hash。如果业务经常要改用户年龄用 String 存整个 JSON 需要先 GET、反序列化、改字段、序列化、再 SET操作复杂且容易产生并发覆盖。用 Hash 只需要HSET user:info:1001 age 19List 适合简单队列但如果有消费者组、消息确认、消息回溯需求更合适的是 Redis Stream。Stream 命令学习成本高一些但功能更完整。ZSet 的 score 可以不只是整数。延迟队列的常见做法是把未来执行时间戳当作 score消费者用ZRANGEBYSCORE拉取当前时间之前的任务。这样做能实现简单延迟任务但需要消费者轮询无法像BLPOP那样阻塞等待。业务要求实时性高时要配合定时调度。3.4 数据结构最容易踩的坑第一个坑是大 key。一个 List 里塞了几百万条缓存数据执行LRANGE list 0 -1会一次性把大量数据返回给客户端内存和网络都会被撑高单线程执行期间还会阻塞其他命令。处理大 key 时要分批删除或异步删除不能直接DEL。第二个坑是过期与不存在的区别。GET一个不存在的 key 返回空不代表 Redis 丢了数据要分清楚是“从未写入”“已过期”还是“被淘汰”。排查时用TTL key查看剩余生存时间用TYPE key查看类型。第三个坑是 ZSet score 精度。业务上如果只是整数排序一般没问题。但涉及到金额、时间戳等大数时要注意浮点数精度可能影响排序结果。需要精确排序时可以把 score 设计成整数或者用多层 Score 组合。4. 核心秘密三持久化、主从复制与集群Redis 从单机走向高可用4.1 为什么缓存也需要持久化RDB 和 AOF很多人误以为 Redis 只做缓存丢了就丢不需要持久化。实际业务里热点数据如果丢失冷启动阶段所有请求会同时打到数据库数据库可能直接被打垮。另外 Redis 还承担分布式锁、消息队列等职责数据丢失会带来重复消费、重复执行等严重问题。Redis 提供两种持久化方式RDB 是全量快照按时间点把内存数据写入二进制文件。恢复快但两次快照之间的数据可能丢失。AOF 是追加日志把写命令追加到文件末尾。数据可靠性更高但文件比 RDB 大恢复速度比 RDB 慢。常见配置save 3600 1 appendonly yes appendfsync everysecsave 3600 1表示 3600 秒内至少有 1 次写操作时触发一次 RDB 快照。appendfsync everysec表示 AOF 每秒刷盘一次兼顾性能和数据可靠性。实际生产环境不能只依赖默认配置建议先执行命令确认当前状态redis-cli CONFIG GET save redis-cli CONFIG GET appendonly redis-cli CONFIG GET appendfsync4.2 用 Docker 快速搭建一个主从复制主从复制的作用是让数据在多个节点上保留副本。主节点负责写从节点同步数据可以承担读请求。当主节点异常时从节点还保留一份可用的数据副本。用 Docker Compose 启动一个主节点和一个从节点services: redis-master: image: redis:7-alpine container_name: redis-master command: [redis-server, --appendonly, yes] ports: - 6379:6379 redis-replica: image: redis:7-alpine container_name: redis-replica command: [redis-server, --replicaof, redis-master, 6379] depends_on: - redis-master ports: - 6380:6379启动后验证docker compose up -d docker exec redis-master redis-cli SET demo:key hello docker exec redis-replica redis-cli GET demo:key docker exec redis-replica redis-cli INFO replication如果主从同步正常从节点能读到helloINFO replication输出中的role字段表示当前节点身份主节点是master从节点是slave。depends_on只能控制容器启动顺序不能保证主节点立即可用。从节点启动后如果连接不上会持续重试并自动建立同步所以不一定需要额外等待逻辑。4.3 哨兵和集群解决什么问题主从复制解决了数据副本问题但没有解决自动故障转移。主节点宕机后如果人工切换业务恢复时间很长。Sentinel 哨兵可以监控主从节点在主节点不可用时自动把某个从节点提升为新的主节点这是生产环境经常采用的方案。Redis Cluster 解决的是扩展问题。集群把数据分成 16384 个哈希槽key 通过 CRC16 运算后对 16384 取模映射到某个槽槽再分布到不同节点。这样数据可以分散到多台机器上单节点内存瓶颈得到缓解。但集群模式下跨节点的多 key 操作有限制客户端要支持集群协议。主从、哨兵和集群定位不同方案解决的核心问题使用代价主从复制数据冗余、读写分离不自动切换主节点故障需要介入哨兵自动故障转移哨兵自身需要高可用部署集群数据水平扩展需要客户端支持跨 slot 操作受限4.4 生产环境不能只看单机学习环境里跑通 Redis 很简单生产环境要考虑的事情更多连接密码、ACL 权限、bind 地址、持久化策略、内存上限、慢日志、监控告警、备份恢复演练、安全组限制。Redis 默认配置更偏“本机可用”不适合直接暴露到公网。高可用不是部署一个集群就结束还要定期演练主节点宕机、从节点提升、数据恢复等操作。很多人集群搭好之后没有演练过真正故障时才发现哨兵配置错误、客户端没有重试逻辑、从节点数据落后主节点太多。Redis 的可靠性最终要靠配置、监控和演练一起保证。5. 环境准备下载、安装、配置与可视化客户端5.1 Linux、Windows 和 Docker 的安装方式不同环境安装 Redis 的方式差别很大。Linux 上最常见的包管理器安装# Debian / Ubuntu apt-get update apt-get install -y redis-server # CentOS / RHEL yum install -y redis源码编译安装适合需要定制版本或部署到内网服务器的场景wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar xzf redis-7.0.14.tar.gz cd redis-7.0.14 make make installmacOS 上可以使用 Homebrewbrew install redis brew services start redisWindows 环境要特别注意Redis 官方没有发布 Windows 版本。网上很多 Windows 安装包是第三方维护或老版本编译的容易出现启动闪退、命令缺失、与新版客户端不兼容的问题。更稳妥