Java Redis “运维”面试清单（含超通俗生活案例与深度理解）
一、Redis报内存不足时，你会采取哪些解决措施？
• 核心考点：内存不足的四种核心解决思路（配置调整、动态优化、策略调整、集群扩容）及各自的适用场景，判断不同场景下的优先级选择
• 理解与通俗例子：
这就像我们常用的手机存储满了的场景，解决逻辑完全可以对应到日常操作，每个方法都有明确的使用场景：
1. 修改配置文件调整最大内存上限：手机默认系统只分配了64GB用于应用存储（对应Redis默认的maxmemory参数），当应用装太多导致内存满时，可通过调整系统配置（如root后修改存储分配参数）将应用存储上限扩到128GB（修改redis.conf中的maxmemory）。这种方式适合长期内存不足，且服务器硬件有多余内存可分配的情况，比如企业内部的用户数据缓存，数据量稳定增长，需要长期扩容内存。
2. 动态设置内存上限临时释放空间：手机突然提示内存满，没法立即调整系统配置（对应Redis无法重启修改配置文件），此时可以临时删除几个不常用的APP（如很久没玩的游戏、冗余的工具类APP），腾出空间安装急需的应用（通过执行“set maxmemory”相关命令动态调整Redis内存上限）。这种方式适合应急场景，比如电商平台大促期间，临时出现订单缓存激增导致内存不足，无需重启Redis就能快速释放空间。
3. 调整内存淘汰策略主动清理旧数据：手机开启“自动清理30天未使用的应用缓存”功能（对应Redis的内存淘汰策略），让系统主动删除长期不用的缓存数据，避免内存被无效数据占满。比如将Redis默认的“noeviction”策略改成“allkeys-lru”，优先删除最久未访问的数据，适合数据有访问频率差异的场景，如商品详情缓存，热门商品频繁访问，冷门商品长期闲置，主动清理冷门数据可释放大量内存。
4. 通过Redis集群实现横向扩容：手机本身存储已扩到最大（如256GB已满），且无法再扩容硬件，此时可以开启云存储功能（对应新增Redis集群节点），将手机里的照片、视频等大容量数据同步到云存储（将Redis数据分摊到多个节点），让本地存储和云存储共同分担压力。这种方式适合单节点内存已达硬件极限，且数据量持续增长的场景，比如社交平台的用户聊天记录缓存，用户量增长导致数据量激增，单节点无法承载。
二、Redis的过期数据回收策略有哪两种？各自的特点是什么？
• 核心考点：两种回收策略（惰性删除、定期删除）的执行逻辑、优缺点对比，以及在实际业务中的适用场景
• 理解与通俗例子：
可以类比“管理家里的书架过期杂志”，书架上的杂志（Redis数据）有阅读有效期，过期后需要清理，两种策略对应两种不同的清理方式：
1. 惰性删除：你平时不会每天翻遍书架检查所有杂志是否过期，只有想读某本杂志时才会去拿——比如周末想读《科技周刊》，抽出来后发现封面标注的“有效期至3个月前”（查询key时发现已过期），才把这本杂志扔进回收站（删除过期key）。
这种策略的优点是“节省精力”：无需频繁花时间扫描所有数据，Redis不用额外消耗CPU资源在定期检查上，适合数据量庞大但过期数据被访问概率低的场景，比如用户的历史订单查询记录，大部分用户不会查看半年前的订单，只有少数情况会查询，此时用惰性删除既能减少CPU消耗，又能在查询时精准清理过期记录。
缺点是“占用空间”：如果过期的杂志一直没被翻阅（过期key未被访问），会一直占着书架位置（内存泄漏）。比如用户注册后再也没登录过，其临时会话key已过期，但因未被查询，长期存留在Redis中，逐渐占用大量内存。
2. 定期删除：你每周六晚上固定花20分钟整理书架（Redis每隔一段时间，如100毫秒，执行一次过期检查），但不会逐格翻看所有杂志（避免遍历所有key消耗过多CPU），而是随机抽出3格书架的杂志（随机选取部分key）——比如上层的生活类、中层的财经类、下层的娱乐类，检查是否有过期的，发现过期就清理（删除过期key）。
这种策略的优点是“主动释放空间”：能定期清理部分过期数据，避免长期堆积，比如每天生成的手机验证码数据，即使未被验证（未被访问），定期删除也能在固定时间清理过期验证码，防止内存被无效数据占满。
缺点是“清理不彻底”：随机扫描会漏删部分过期数据——比如书架角落的《体育画报》已过期，但周六整理时没随机抽到那格，就会继续占用空间，直到下次检查或被翻阅。另外，检查频率过高（如每秒一次）会消耗过多CPU，频率过低（如每小时一次）又会导致过期数据堆积时间过长。
三、Redis有哪些内存溢出控制策略？默认策略是什么？实际业务中该如何选择？
• 核心考点：六种策略的具体逻辑差异、默认策略的特点，以及不同业务场景下的策略匹配思路
• 理解与通俗例子：
当家里的冰箱（Redis内存）已塞满食物，再也放不进新食材时，六种策略对应六种“处理新食材”的方式，默认策略是noeviction，每种策略都有明确的适用场景：
1. noeviction（默认策略）：冰箱里的食物已堆到柜门关不上，你既不扔掉任何现有食物（不删除任何数据），也不让新食材放进冰箱（拒绝所有写入操作，返回错误信息），只能从冰箱里拿已有的食物吃（仅响应读操作）。这种策略适合数据绝对不能丢失、不允许删除任何数据的场景，比如银行的交易流水缓存，每一条流水都涉及资金记录，即使内存满了，也只能拒绝新流水写入，不能删旧流水，避免数据缺失。
2. volatile-lru：你只针对冰箱上贴了“短期食用”标签的食物（仅删除设置了expire过期时间的key），且优先扔掉“放最久没吃”的（按LRU算法，即“最近最少使用”）——比如贴了标签的酸奶，已放了5天没喝，就先扔掉，腾出空间放新买的牛奶。这种策略适合“有过期属性的数据可清理，非过期数据需保留”的场景，比如用户的登录会话缓存，会话设2小时过期，内存满时删最久没活动的会话，而用户的基础信息缓存（无过期时间）则保留。
3. allkeys-lru：不管食物有没有贴标签（无论数据是否设expire），都优先扔掉“放最久没吃”的——比如冰箱里的冷冻肉，虽没贴“短期食用”标签，但已冻了3个月没吃，就拿出来解冻处理，给新买的海鲜腾空间。这种策略适合“数据无明显过期属性，但有访问频率差异”的场景，比如电商的商品评价缓存，评价数据不会主动过期，但有的冷门商品评价几个月没人看，有的热门商品评价每天被浏览多次，内存满时删冷门评价，保证热门评价能快速访问。
4. allkeys-random：闭着眼睛从冰箱里随便拿出几件食物（随机删除所有key），不管是否常用、有没有标签——比如伸手从冰箱中层随便拿两盒食材，不管是刚买的蔬菜还是放了一周的罐头，都暂时拿出来放厨房台面上。这种策略适合“数据访问频率均匀，删除任意数据对业务影响小”的场景，比如临时的用户访问量统计，每小时统计一次，数据仅需保留1小时，内存满时随机删部分统计数据，对整体统计结果影响极小。
5. volatile-random：只从贴了“短期食用”标签的食物里，随便拿几件出来（随机删除设expire的key）——比如冰箱里有8件贴标签的食材，随便拿2件，不管是刚放的鸡蛋还是放了3天的面包。这种策略适用场景较窄，仅适合“过期数据可随机清理，无需按访问频率筛选”的情况，比如临时生成的活动优惠券，每张优惠券有1小时有效期，内存满时随机删几张过期优惠券，不会影响用户使用。
6. volatile-ttl：看贴了“短期食用”标签的食物上写的“最佳食用截止日”（key的ttl属性，剩余过期时间），优先扔掉“快到截止日”的——比如两件贴标签的食材，一件还有1小时过期，一件还有1天过期，就先删只剩1小时的。这种策略适合“需精准清理即将过期数据，尽量保留有效期长的数据”的场景，比如限时折扣活动缓存（如“还有10分钟结束的满减活动”），内存满时先删快结束的活动缓存，保留还有较长时间的活动，避免用户看不到未结束的优惠。
四、Redis发生阻塞时，你会从哪些维度排查？对应的解决办法是什么？
• 核心考点：阻塞的三大常见原因（API/数据结构不合理、CPU饱和、持久化相关问题）、排查工具与步骤，以及针对性的解决方案
• 理解与通俗例子：
Redis阻塞就像奶茶店出餐变慢，原本5分钟能拿到的奶茶，现在要等30分钟，需从“制作流程、订单量、辅助工作”三个维度排查，每个问题都有对应解决办法：
1. API或数据结构使用不合理：
奶茶店让店员“一次制作100杯同一口味的奶茶”（对应Redis中在大对象上执行高复杂度命令），店员需要反复煮茶、加配料，花了25分钟才做完（命令执行耗时过长），期间其他口味的奶茶订单全被搁置（Redis阻塞）。比如用“hgetall”查询包含10万个字段的hash key，相当于一次处理100杯奶茶，耗时极长。
排查方法：通过“slowlog get 10”命令查看最近10条慢查询命令，快速定位像“hgetall”“keys”这类耗时命令。
解决办法：① 替换低复杂度命令：把“hgetall”改成“hmget”，只查询需要的3个字段（相当于一次做3杯奶茶，而非100杯）；禁用“keys”“sort”等遍历性命令，用“scan”替代“keys”做增量查询。② 拆分大对象：把10万个字段的hash拆成100个小hash，每个存1000个字段（相当于把100杯奶茶分10批做，每批10杯），避免一次处理过多数据。
2. CPU饱和的问题：
奶茶店只有1个店员（Redis单线程），平时每天接50单（低并发），能轻松应对；周末突然来了500单（高并发），店员从早忙到晚，CPU使用率达98%（Redis单核CPU饱和），出餐速度自然变慢。
排查方法：用“redis-cli -h 服务器IP -p 端口 --stat”查看Redis的每秒命令处理数（OPS），若OPS超过单节点极限（一般单节点OPS在1万-5万，取决于命令复杂度），说明CPU饱和源于高并发。
解决办法：① 横向扩容：新增2个店员（2个Redis集群节点），把500单分给3个店员，每人处理约167单（分摊OPS压力）；② 优化命令：若OPS低却CPU高，检查是否有“sort”“union”等复杂命令，或频繁触发内存淘汰导致的CPU消耗，针对性优化。
3. 持久化相关的阻塞：
店员制作奶茶时，还要兼顾“记录订单明细”（Redis持久化），若记录工作耗时过长，会耽误出餐（Redis阻塞），具体分三种情况：
◦ fork阻塞：奶茶店每天打烊后要“整理当天所有订单的纸质档案”（RDB持久化），整理前需把500张订单复印一份（fork操作生成子进程），复印花了15分钟（fork耗时过长），期间店员没法准备第二天的食材（主线程阻塞）。fork耗时与Redis内存正相关，内存越大，fork越慢。
解决办法：控制Redis内存在10GB以内，减少fork耗时；避开下午茶高峰期（业务高峰）做RDB备份，改到凌晨2点（低峰期）执行。
◦ AOF刷盘阻塞：店员每做一杯奶茶，都要把订单号记在笔记本上（AOF日志），每天晚上固定把笔记本内容抄到正式账本（fsync刷盘）。若账本已写满（硬盘空间不足），抄录花了10分钟（硬盘IO压力大），期间店员没法记新订单（主线程阻塞）。
解决办法：更换SSD硬盘（IO速度比机械硬盘快10倍以上）；调整AOF刷盘策略为“每秒一次”（appendfsync everysec），平衡性能与数据安全性，避免“每次写都刷盘”的高IO消耗。
◦ HugePage写操作阻塞：店员平时用小本子记订单，每页记5条（对应4KB内存页），改订单时翻1页就行；后来换成大本子，每页记2000条（开启Transparent HugePages，内存页2MB），改一条订单要翻整页大本子（修改内存页需复制2MB数据），比原来慢400倍（写操作耗时增加）。
解决办法：关闭系统Transparent HugePages，Linux系统中通过“echo never > /sys/kernel/mm/transparent_hugepage/enabled”临时关闭，再修改配置文件确保重启后生效，恢复4KB小内存页模式。
五、什么是Redis大key？有哪些危害？如何查找和处理？
• 核心考点：大key的定义标准、对Redis的负面影响、排查工具的使用方法，以及不同类型大key的处理方案
• 理解与通俗例子：
1. 什么是大key？
就像旅行时的“异常行李箱”，主要分两类：① 单个行李箱超重（string类型value超过10KB，比如存一段15MB的视频日志、一张高清图片的Base64编码）；② 行李箱里装了过多物品（hash、set、zset、list等集合类型，元素数量超过1万个，比如一个list存5万个用户的留言消息，一个set存20万个用户ID）。比如教育平台的“课程回放视频缓存”，用string类型存视频片段，单个value达20KB，就是典型的大key。
2. 大key有什么危害？
◦ 访问耗时过长：搬运超重行李箱（访问大key）要花10分钟，比普通行李箱（小key）的1分钟慢10倍（客户端请求超时）。比如用户查询包含5万条留言的list大key，原本预期1秒加载，实际要12秒，用户直接退出页面。
◦ 占用过多资源：一个超重行李箱占满电梯空间（带宽），其他行李箱没法进（小key传输被阻塞）；整理行李箱时要逐个清点物品（遍历集合元素），消耗大量体力（CPU资源）。比如1个20MB的string大key传输一次，占用20MB带宽，相当于同时传输20个1MB的小key，导致其他请求排队。
◦ 集群数据倾斜：所有超重行李箱都分给一个搬运工（集群节点），其他搬运工只搬小行李箱，这个搬运工累到罢工（节点内存、CPU满负荷），其他却很闲（数据倾斜）。比如Redis集群3个节点，一个节点存所有课程视频大key，内存用了9GB，其他两个节点各用1GB，负载严重不均。
◦ 删除时阻塞Redis：扔掉超重行李箱前，要逐个拿出里面的物品（删除集合元素），花了30分钟（阻塞主线程），期间没法搬运其他行李（Redis无法处理新命令）。比如用“DEL”删除包含20万个元素的set大key，Redis需逐个删除元素，耗时20秒，期间所有命令排队。
3. 怎么找到大key？
◦ 用bigkeys命令快速定位：相当于问搬运工“你手里最重的行李箱是哪个？”，在Redis客户端输入“bigkeys”，会遍历所有key，统计各类型key的平均大小，返回每种类型的最大key（如string类型最大key是“course:1001:video”，大小22KB；list类型最大key是“user:10086:message”，元素数6万）。优点是无需重启Redis，适合快速排查；缺点是遍历key会消耗CPU，建议低峰期执行。
◦ 用redis-rdb-tools分析RDB文件：相当于翻旅行团的“行李登记册”（RDB快照文件），这个Python工具能将RDB文件转换成报表，详细列出每个key的大小、元素数、修改时间。比如分析“dump.rdb”后，能筛选出所有超过10KB的string key和元素超1万的集合key，适合离线全面排查大key，不影响Redis运行。
4. 怎么处理大key？
◦ 安全删除：① Redis 4.0+用“UNLINK”命令，相当于分多次搬空行李箱——先拿100件物品，中间搬几个小行李箱，再拿剩下的（非阻塞删除），比如“UNLINK course:1001:video”，后台异步删除，主线程不阻塞。② 4.0以下用“SCAN”分批删除，比如删除6万元素的list，用“LRANGE”每次取1000个元素，再用“LTRIM”删除，分60次完成，避免一次阻塞。
◦ 压缩体积：string类型大key（如视频日志）用Gzip压缩，相当于把行李箱抽成真空，体积缩小到原来的1/4，比如22KB的日志压缩后变5.5KB，减少内存占用和传输耗时。注意压缩和解压缩会消耗CPU，适合访问频率低的场景（如后台日志查询）。
◦ 拆分大key：① string大key拆分：把20KB的视频日志拆成4个5KB的小key，如“course:1001:video:1”到“course:1001:video:4”，查询时用“MGET”批量获取。② 集合大key拆分：把6万元素的留言list，按日期拆成“user:10086:message:202405”（5月留言，1.5万元素）、“user:10086:message:202406”（6月留言，1.5万元素），每个list元素数控制在2万以内，避免大key危害。
六、Redis常见的性能问题有哪些？对应的解决方案是什么？
• 核心考点：主从架构、持久化、集群部署中的性能痛点，以及基于业务场景的优化思路
• 理解与通俗例子：
就像运营连锁超市的供应链，要避免“总部太忙、分店补货慢、数据记录影响效率”等问题，Redis性能优化围绕这些核心场景展开：
1. Master节点承担持久化导致性能下降：超市总部（Master）既要接收各分店的补货订单（处理Redis写命令），又要自己记录所有订单的纸质台账（做RDB/AOF持久化），导致处理订单的速度变慢（Master性能下降）。Master做持久化时，fork子进程、写磁盘会消耗大量CPU和IO，尤其是AOF重写，会占用内存和IO资源，拖慢命令处理速度。
解决办法：让Master专注处理业务，把持久化交给分店（Slave）。比如总部只接收补货订单，让分店1负责记录台账（开启AOF持久化），AOF刷盘策略设为“每秒一次”，既保证数据最多丢1秒，又不占用总部资源；若数据关键，让分店2也开启RDB备份，做双重保障，避免总部因持久化消耗性能。
2. 主从复制速度慢、连接不稳定：超市总部在市区（Master），分店在郊区（Slave），总部用货车给分店送补货清单（数据同步），因距离远，货车要走1小时（网络延迟高），遇到堵车还会中断（连接不稳定），分店的清单总是比总部慢（数据同步延迟）。主从跨局域网时，高延迟和低带宽会导致Slave同步慢，甚至断连，影响数据一致性。
解决办法：① 主从部署在同一局域网，如分店搬到市区总部附近，货车10分钟就能到（网络延迟低于1ms），同步速度快且稳定。② 优化复制参数：增大“repl-backlog-size”（复制积压缓冲区），Slave断连后重新连接时，能从缓冲区获取断连期间的增量数据，不用重新全量同步（相当于货车断连后，不用重拉所有清单，只补断连期间的新清单）。③ 控制Slave数量，一个Master最多挂4个Slave，避免总部因给太多分店送清单（同步数据）消耗过多带宽。
3. 高压力时给Master新增Slave：超市总部正处于促销期（Master高并发），每天接2000个补货订单，忙得不可开交，还强行开一家新分店（新增Slave），总部需要给新分店送所有历史补货清单（全量同步），导致处理新订单的速度变慢（Master性能骤降）。新增Slave时，Master要执行“bgsave”生成RDB文件，再传给Slave，这个过程消耗大量CPU和IO，高压力下会严重拖慢Master。
解决办法：① 避开高压力时段新增Slave，促销期过后（低峰期）再开新分店。② 采用“Slaveof Slave”模式：新分店不直接连总部，而是连已同步完数据的分店1，让分店1给新分店传清单（全量同步），总部无需参与，不影响性能（相当于新分店从老分店拿清单，不麻烦总部）。
4. Master执行BGREWRITEAOF导致服务暂停：超市总部（Master）每月要“重新整理台账”（BGREWRITEAOF），把零散的订单记录合并成一本厚台账（合并AOF日志，减少文件大小），整理花了1小时（AOF重写耗时），期间总部没法接收新订单（Master短暂阻塞）。BGREWRITEAOF时，Masterfork子进程会阻塞主线程，重写过程还会占用内存和IO，导致命令处理变慢。
解决办法：① 让Slave执行BGREWRITEAOF，分店1整理完台账后，再把台账传给总部（如需），避免总部消耗资源。② 调整重写触发条件：增大“auto-aof-rewrite-min-size”（AOF最小重写大小）和“auto-aof-rewrite-percentage”（AOF增长率），让重写只在AOF文件足够大且增长快时触发，避免频繁重写。③ 低峰期手动执行，如每天凌晨3点（订单最少时）执行BGREWRITEAOF，即使有短暂阻塞，也不影响业务。
5. 主从用图状结构导致不稳定：超市总部（Master）同时给3家分店送清单（图状结构：Master→Slave1、Master→Slave2、Master→Slave3），总部突然停电（Master宕机），3家分店都要重新找总部（切换主从），且分店清单数据不一致（有的同步到最新，有的没同步完），导致补货混乱。图状结构中，Master负载高，宕机后Slave切换复杂，易出现数据不一致。
解决办法：用“单向链表结构”部署，即Master→Slave1→Slave2→Slave3，总部只给分店1送清单，分店1给分店2送，分店2给分店3送。优点：① Master负载低，只同步1个Slave；② Master宕机后，分店1直接当新总部，分店2、3继续从分店1拿清单（无需改配置），切换简单且数据一致。比如零售平台的商品库存缓存，用链表结构，Master宕机后1分钟内切换到Slave1，用户几乎无感知。