先说个挺现实的现象现在后端岗位面试十个里至少有八个会问Redis。项目里要做缓存、做分布式锁、做排行榜、做消息队列轻量替代也基本都是Redis。很多同学手里存了一堆教程真到用的时候又发现要不就是文档太长翻不到重点要不就是照着一堆命令敲完根本不知道每个操作背后是为了解决什么问题。这篇速记就是冲着这个痛点去的——把Redis从安装部署、核心数据结构、持久化策略到主从哨兵、分布式锁、缓存治理这些高频知识压成一份能直接拿来复盘和实战的笔记。里面涉及的操作我都实际跑过涉及的坑也是踩过之后才写出来的不管是准备面试还是想快速上手都建议配合手边的实例一起过一遍。1. Redis到底是什么以及为什么大家都在用它1.1 它解决的不是存储问题而是速度问题很多初学者会把Redis理解成一个花哨的数据库其实更准确的说法是它是一层放在应用和数据库之间的高速缓冲层。传统关系型数据库的数据落在磁盘上每次查询要经过磁盘I/O在高并发场景下延迟会迅速上升Redis把数据放在内存里单线程模型配合I/O多路复用读写性能能轻松跑到每秒十万次以上。所以它被人记住的第一印象往往是“快”但它真正解决的是“把热点数据从慢速存储中挪出来让高频请求不再打到数据库上”的问题。也正是因为基于内存Redis的数据天然带有一个特点断电会丢。于是后面延伸出了持久化、主从复制、哨兵机制这些话题。理解主线很重要——Redis不是一个万能的存储而是一套围绕“高性能”“高可用”“易扩展”三个关键词构建的缓存与数据结构服务器。1.2 你能用它做什么哪些场景不适合从实际项目看Redis最常见的应用面覆盖这几个方向缓存热点数据比如用户信息、商品详情、配置项减少数据库压力。分布式场景下的共享会话、幂等校验、分布式锁。排行榜与计数场景靠有序集合和原子自增操作。轻量级消息队列靠List类型的阻塞读取能力做简单的发布/订阅。分布式限流、UV统计、签到记录、好友关系等场景分别对应不同类型的底层结构。但Redis解决不了所有问题比如它不适合存大规模全量业务数据一是内存成本太高二是持久化机制和事务能力远不如关系型数据库完整。把“缓存”当“主存储”用早晚要出问题。这一点在做架构选型时一定要拎清楚。1.3 这份速记适合谁如果你正在准备面试重点看第2节的数据类型、第5节的事务与分布式锁以及第7节的缓存治理如果你是刚入职要快速上手项目先看第3节的部署和第6节的可视化工具与序列化这决定了你能不能连上环境、能不能看懂数据要是你已经负责线上Redis了第4节的主从哨兵和第7节的排查问题建议直接对照实际环境复现一遍。原子化理解加上动手验证比死记命令牢固得多。2. 核心数据类型不只是缓存还是数据结构服务器2.1 五种基础类型的使用场景与底层思路Redis官方把自身定义为数据结构服务器这个定位比“缓存”更准确。它提供了多种数据结构每个结构都对应一类经典问题搞懂结构选型比背命令重要得多。String字符串最基础的键值结构value最大512MB。除了存普通字符串还能存数字所以自增自减操作INCR、DECR经常用来做计数器、秒杀库存、点赞数等。底层是SDS简单动态字符串相比C字符串可以在O(1)时间获取长度并且避免缓冲区溢出。Hash哈希适合存储对象结构比如用户信息、商品信息。它比多个String更省内存也便于统一管理。底层在数据量小的时候用ziplist压缩列表数据量大后转为hashtable。项目里存用户信息时我一般优先用Hash而不是把整个对象序列化成JSON塞进一个String——后者一旦要改某个字段就得整个读出再写回。List列表底层是quicklist结构本质上是一个链表。经常用来做消息队列、时间线列表、最新公告。BRPOP这类阻塞读取命令甚至可以让多个消费者协调消费这是实现轻量级MQ的关键。Set集合元素无序且唯一适合做去重、共同好友、关注关系等场景。底层是intset或hashtable。它的一个重要特性是支持集合运算比如SINTER求交集能快速算出两个用户共同关注了哪些账号。ZSet有序集合每个元素带一个score按分数排序。底层是跳表skiplist加哈希表这也是Redis面试高频考点之一。典型场景包括排行榜、延迟队列按时间戳作为score、限流窗口统计。2.2 三个容易忽略的高级类型Bitmap位图String类型的一种位操作形态可以用来做用户签到、在线状态统计。一个月 31 天用 31 个 bit 就能表示一个用户整月签到记录非常省空间。HyperLogLog基数统计用于海量数据去重计数比如UV统计标准误差约0.81%。它不会存储具体元素只存储统计结果适合只追求数量不追求明细的场景。Geo地理坐标底层还是ZSet围绕经纬度做附近的人、门店距离计算省去自己实现空间索引的工作。2.3 一个实操案例用户最近浏览记录设计举一个综合例子要记录用户最近浏览的10件商品。具体做法是用List把商品ID用LPUSH每次插到头部然后LTRIM只保留前10个。这样每次浏览就是两次操作读取时用LRANGE取全量就好。这个方案在多数项目里都能直接落地比数据库查询实时拼接要轻得多。注意如果只是存最近浏览不考虑去重List够用了如果同一个商品反复浏览要置顶且去重就需要用ZSet把商品ID作为member把浏览时间戳作为score取列表时按score倒序。两种方案的差异要在设计时提前想清楚。3. 安装与部署从Windows本机到Docker生产环境3.1 本机环境准备Windows和Linux都行Redis官方支持LinuxWindows版本并非官方原生支持但微软团队和开源社区维护了可用于开发的Windows移植版。如果只是在本地写代码调试完全可以直接下载Windows版本压缩包解压后运行redis-server.exe默认端口6379再跑一个redis-cli.exe即可连接。国内下载的话会看到很多镜像站优先选择了解的开源镜像站或者官方仓库避免下载到捆绑软件。Linux下的安装更典型常见有两种方式包管理器安装或者源码编译。以CentOS系为例# 包管理器 yum install redis -y systemctl start redis # 源码编译 wget https://download.redis.io/releases/redis-6.2.5.tar.gz tar xzf redis-6.2.5.tar.gz cd redis-6.2.5 make make install redis-server如果是Ubuntu系把yum换成apt-get即可。源码编译时如果没有gcc环境先执行yum install -y gcc gcc-c否则编译过程会报错。这里顺便吐槽一下很多新手栽在编译依赖上其实错误提示已经说得很明白了只是没仔细看。3.2 Docker部署与docker-compose生产配置如果团队已经有容器化环境用Docker部署Redis是最快的路径。单机运行一条命令docker run -d --name redis \ -p 6379:6379 \ -v /data/redis:/data \ redis:6.2.5 --appendonly yes但生产环境一般不会裸跑容器而是用docker-compose把配置、数据目录、日志统一管理起来。下面是一份我在生产环境实际使用的docker-compose配置做了简化但保留了核心要素version: 3.8 services: redis: image: redis:6.2.5 container_name: redis-master restart: always ports: - 6379:6379 command: [redis-server, /usr/local/etc/redis/redis.conf] volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf - ./data:/data - ./logs:/logs environment: - TZAsia/Shanghai这里有几个关键点command里显式指定了配置文件路径这是为了让容器启动时读取我们挂载的配置而不是用镜像默认配置。数据目录和日志目录都挂载到宿主机防止容器删除后数据全部丢失。生产环境务必开启持久化一般建议AOF持久化为主RDB为辅具体见第4节。3.3 安装完成的验证与常见问题启动完成后用redis-cli ping返回PONG即代表服务正常。这时候可以用info memory、info clients查看基础状态。我见过一个特别常见的启动问题Linux下redis默认只监听127.0.0.1外部客户端连不上。解决办法是修改配置文件里的bind为0.0.0.0同时设置protected-mode no但生产环境千万不能只图方便打开必须配合密码认证requirepass一起用。注意Windows下的Redis服务默认也没有密码且端口直接暴露局域网内任何人都可以连接。本地调试无所谓但如果是在公司内网机器上开放端口至少设置requirepass否则很容易被别人扫到然后利用未授权访问漏洞。4. 持久化机制为什么重启后数据还在4.1 RDB快照跑得快但丢数据窗口大RDBRedis DataBase是Redis默认的持久化方式它会生成一个压缩的二进制快照文件dump.rdb。通过fork子进程生成快照所以不会阻塞主线程太久。配置项里常见的save 900 1表示900秒内至少有1次写操作就触发一次快照。优点是文件紧凑、恢复速度快。缺点也明显因为是定时快照如果Redis在两次快照之间宕机这段时间内写入的数据就会丢失。所以RDB适合做数据备份、迁移、冷启动恢复不适合作为唯一可靠性保障。4.2 AOF日志更可靠但要管好重写AOFAppend Only File以日志形式记录每次写操作恢复时重放这些操作。默认fsync策略是everysec即每秒刷盘一次最多丢失一秒数据可靠性比RDB高很多。但AOF文件会不断增长所以有了重写机制Redis会根据当前内存状态生成最小命令集合并覆盖旧的AOF文件。在生产里我一般这样配置appendonly yes appendfilename appendonly.aof appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mbauto-aof-rewrite-percentage 100表示AOF文件比上次重写时增长100%就触发重写64mb是触发重写的最小体积避免刚启动就反复重写。4.3 混合持久化一个兼顾速度和安全的折中方案Redis 4.0以后支持aof-use-rdb-preamble开启后AOF文件开头是RDB格式的头部快照后面追加增量命令。这样重启恢复时先快速加载RDB头再重放少量增量日志恢复速度和可靠性都兼顾了。生产环境我一般推荐打开这个选项。提示只开AOF时如果AOF文件因为停电等原因出现尾部损坏Redis默认启动会拒绝加载。可以用redis-check-aof --fix修复工具尝试修复。同理RDB文件损坏可以用redis-check-rdb检查。这两个工具在bin目录下很多人并不知道它们的存在关键时刻非常救命。5. 主从架构与哨兵模式高可用的基石5.1 主从复制的原理和配置方式单机Redis一旦宕机缓存全部失效数据库会被突来的流量打垮。最常见的高可用方案是主从复制一个master节点负责写多个slave节点负责读master会把写操作异步同步给slave。这样做既分担读压力也提供数据冗余。从节点配置很简单在slave的redis.conf里加上replicaof 主节点IP 6379或者运行时直接命令redis-cli REPLICAOF 主节点IP 6379如果迁移到了Redis 5.0以上版本建议用replicaof代替旧的slaveof。主从复制全量同步时master会生成RDB快照发给slave后续再增量同步命令。这里有个容易踩的坑如果主节点开启了持久化从节点数据是完整的如果主节点没开持久化重启后数据丢了从节点也会被覆盖成空数据。5.2 哨兵模式自动故障转移主从复制能备份数据但master宕机后写服务就中断了需要人工把某个slave提升为master。哨兵Sentinel解决的就是这个问题它监控所有节点当master故障时自动执行故障转移把某个slave晋升为master并通知其他slave重新指向新master。搭建哨兵至少需要3个实例奇数保证选主投票能过半数。关键配置项sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 150002表示至少2个哨兵同意master客观下线才能触发故障转移。这个值必须根据哨兵数量计算比如3个哨兵时就写25个哨兵时可以写3。生产里常见的一个坑是哨兵网络抖动导致误判所以down-after-milliseconds不建议设置太短一般5到10秒比较合理。5.3 用Docker快速搭建一主两从三哨兵手工部署三台机器比较麻烦用Docker Compose可以快速体验完整流程。思路是启动一个master、两个replica、三个sentinel容器然后手动停掉master观察哨兵是否自动把某一个replica提升为新master。因为涉及容器间通信每个节点都要设置独立端口和容器网络。关于Docker方式搭建主从哨兵网上已有不少现成compose文件但如果你只是做本地验证我更建议用redis官方提供的sentinel配置模板逐个改端口、启动进程在启动过程中留意日志里的switch-master事件。看到这个事件就说明哨兵已经完成了故障转移这个过程值得亲手跑一遍面试时讲起来非常加分。6. 事务、分布式锁与内存淘汰策略6.1 Redis事务看起来像事务但不是你想的那种Redis事务用MULTI、EXEC、DISCARD、WATCH四个命令实现。MULTI开启事务中间的命令会放入队列EXEC一次性执行。和关系型数据库不同Redis事务不支持回滚如果某条命令语法错误队列里所有命令都会拒绝执行如果只是运行时报错其他命令依然执行。所以它本质上只是“批量执行”加“隔离性”没有原子性保证。WATCH命令提供了乐观锁能力可以在EXEC之前监视一个或多个key如果这些key在事务执行前被其他客户端修改了事务会被打断。这个特性在实现一些简易的CAS比较并交换操作时非常有用。6.2 分布式锁从SETNX到Redisson分布式场景下多个进程需要互斥访问共享资源最经典的做法就是基于Redis实现分布式锁。早期版本用SETNX加EXPIRE两条命令但存在设置锁和过期时间非原子的问题后来官方在SET命令上扩展了参数一条命令搞定SET lock_key unique_value NX PX 30000NX只有当key不存在时才能设置相当于加锁。PX 30000过期时间30秒防止持有锁的进程崩溃后死锁。unique_value必须是每个客户端唯一的随机值释放锁时用Lua脚本判断并删除避免误删别人的锁。释放锁的正确姿势是配合Lua脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end生产项目中我优先建议直接用Redisson框架它封装了看门狗自动续期机制能避免业务执行时间超过锁过期时间导致提前释放的问题。面试题里的“分布式锁怎么实现”最好能答出SETNX加过期时间、唯一标识、Lua释放锁这几个层次再提到Redisson这就是一个完整答案。6.3 内存淘汰策略Redis内存满了怎么办Redis默认在内存达到maxmemory后写入操作会直接报错。生产环境几乎都会配置一个淘汰策略。最高频的几个noeviction内存满了不淘汰直接返回错误默认值不适合缓存场景。allkeys-lru从所有key中按LRU最近最少使用淘汰。volatile-lru只从设置了过期时间的key中按LRU淘汰。allkeys-lfu / volatile-lfuLFU最不经常使用针对访问频率的淘汰策略适合有明显热点变化的场景。我实际用下来缓存场景用allkeys-lru最省心如果部分key不能丢比如分布式锁就要用volatile开头策略并给这些key设置过期时间。还有一个小细节maxmemory不要设满给系统留出至少20%的余量否则内存碎片和持久化fork都可能出问题。7. 可视化工具、客户端连接与序列化问题7.1 从桌面客户端到RedisInsight命令行操作Redis终归效率不高日常排查和调试强烈建议配一个可视化工具。老牌的Redis Desktop Manager现在叫RedisInsight的前身之一在新版本里改为免费并可跨平台使用另一个非常流行的开源替代是Another Redis Desktop Manager界面清爽、功能齐全支持key的模糊搜索、内存分析、慢日志查询、命令行窗口等我目前主力用的是这个。连接远程Redis时记得填写密码没有密码的实例要小心。连接工具本身不会解决权限问题真正的安全策略来自服务端配置。7.2 Java/Spring Boot中的Redis序列化问题在后端项目中使用Spring Data Redis最常见的坑就是序列化方式不一致。默认的JdkSerializationRedisSerializer会把对象序列化成二进制可读性差而且跨语言不友好。很多同学遇到“用命令行看到的是乱码用Java读出来却是对象”的问题根因就在这里。推荐的组合是key使用StringRedisSerializer方便肉眼查看。value使用Jackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer转成JSON。自定义对象建议带上类型信息否则反序列化时有可能丢失类型导致转换异常。下面是一段常见配置Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; }提示改序列化方式前务必考虑已有数据的兼容性。如果线上已经用JDK序列化存了大量数据贸然切换会导致旧数据读不了最安全的做法是换新key逐步迁移而不是原地改配置。8. 缓存治理穿透、击穿、雪崩与日志排查8.1 三个必须从原理上搞懂的缓存问题缓存穿透查询一个必定不存在的数据请求绕过缓存直接打到数据库。最典型的是恶意攻击者不断请求不存在的用户ID。解决办法对空结果也做缓存但过期时间要短或者用布隆过滤器在缓存前拦截不存在的数据。缓存击穿某个热点key在过期瞬间大量请求同时打到数据库。解决办法是热点key不设置过期时间后台异步更新或者用互斥锁保证同一时刻只有一个线程查数据库并回填缓存。缓存雪崩大量key在同一时间段集中过期导致数据库请求量峰值陡增。解决办法是过期时间加上随机值打散过期时间也可以采用多级缓存本地缓存配合Redis另外保证Redis高可用避免Redis宕机引发全量穿透。这三个问题在面试中的出现频率非常高建议结合项目实际场景提前准备好话术你们项目遇到过哪个问题、怎么发现、怎么解决的。8.2 Redis日志与慢日志排查线上Redis如果突然变慢日志是排查的第一步。Redis的日志级别有debug、verbose、notice、warning生产一般设为notice。开启慢日志可以定位哪些命令耗时较高CONFIG SET slowlog-log-slower-than 10000 CONFIG SET slowlog-max-len 128上面配置含义是执行时间超过10毫秒的命令记录到slowlog最多保留128条。然后通过SLOWLOG GET查看慢命令。常见的大key操作、SORT、KEYS命令都容易触发慢日志。特别是KEYS命令生产环境千万别用它会阻塞整个实例正确替代品是SCAN命令分批扫描key而不阻塞主线程。8.3 一个缓存治理的实战排查思路如果线上出现“数据库压力突然升高”我习惯按这个顺序排查先看Redis的QPS和命中率命中率骤降说明大量key集中过期属于雪崩或穿透再查慢日志里有没有耗时的命令排除大key问题接着看内存淘汰日志确认是否因为内存不足把缓存key全部淘汰了最后看服务端连接数如果连接数满可能是客户端连接池配置不合理。这套思路配合可视化工具的慢日志、内存分析面板基本能覆盖90%的缓存异常场景。排查时不要只看Redis本身也要结合应用日志和数据库慢查询把整个调用链串起来才能定位根因。9. 面试高频误区与速记自查9.1 几个最容易被问倒的盲区Redis为什么快很多人只答“基于内存、单线程避免竞争”更完整的答案还要包括I/O多路复用、高效的数据结构、全局哈希表。Redis单线程为什么还这么快核心是Redis的操作基于内存且通过事件驱动模型处理并发连接IO耗时本身不在主进程里包括持久化fork子进程也不会阻塞主线程。Redis事务可靠吗答案是不可靠不支持回滚不是ACID事务。这个一定要讲清楚。缓存和数据库的一致性怎么做没有银弹常用方案有Cache Aside模式先更新数据库再删除缓存、延迟双删、异步消息队列配合binlog订阅。面试时能说出各种方案的优缺点就够了。大key怎么处理先通过redis-cli --bigkeys扫描然后拆分比如hash分片、压缩、异步删除用UNLINK代替DEL避免阻塞。热key如何发现可以通过redis-cli的monitor命令抽样或者客户端统计访问频率。优化手段包括多级缓存、本地缓存、key打散等。9.2 速记自查清单String能存的最大值是多少512MBHash底层什么时候用ziplist什么时候用hashtable元素少且值小时用ziplist为什么ZSet用跳表而不用红黑树跳表实现简单、范围查找方便RDB和AOF各适合什么场景RDB做备份、AOF做可靠性哨兵判断master下线需要几个同意取决于quorum配置建议过半分布式锁为什么需要唯一标识防止误删他人锁过期时间为什么要加随机值防止雪崩内存淘汰策略和生产场景怎么选缓存建议allkeys-lru慢日志命令是什么SLOWLOG GET如何安全遍历所有keySCAN不用KEYS这份清单背后的原理如果自己都能顺畅讲明白Redis这条线基本就稳了。真到面试时能画出架构图、讲出命令背后的数据结构、结合项目说明选型理由就很加分。10. 个人经验和最后的小技巧我最初接触Redis时也是纯看文档觉得命令就是那些、没什么了不起的真到了线上排查一次缓存雪崩才意识到对底层机制的理解决定了能不能快速定位问题。现在团队里新同学入职我一般建议他们用Docker在本地把一主两从三哨兵环境搭一遍亲手停掉master节点看看发生了什么这个过程比看十篇文章都生动。最后分享一个平时用得最多的排查命令组合先redis-cli info memory看内存占用再redis-cli --bigkeys扫大key最后SLOWLOG GET 20看慢命令。三个命令加起来用不了一分钟却能把Redis实例最常见的三类隐患摸个大概。希望这份速记在你自己动手搭建和排障时能帮你少走点弯路。
