Redis 这个东西我在项目里用了不少年头了。说实话刚接触那会儿我完全没把它当回事觉得不过就是个远程缓存、存几个 key-value直到后来线上因为一个简单的 incr 操作报了错再加上分布式锁处理不当导致超卖问题才逼着自己把它的底细啃完。这篇我不照着官方文档念把真正用得上、踩过坑的部分摘出来从安装到数据类型从持久化到主从哨兵集群再到最常见的 RedisTemplate 序列化引发的 increment() 报错一次性讲清楚。无论你是刚入门的小白还是已经写过几个 Redis 工具类的后端开发都应该能挑到有用的东西。1. Redis到底是个什么先把它讲明白1.1 我最初的几个误解很多新手听到 Redis第一反应是“内存数据库”然后就跑去把它当关系型数据库用存一大堆有复杂关联的业务数据结果查询、一致性、内存占用全出问题。我刚开始也犯过这个错。另一个更常见的误解是“Redis 是单线程的肯定很弱”但实际上单线程模型反而让它在绝大多数场景下避免了锁竞争和上下文切换配合 IO 多路复用单实例性能能做到非常可观完全能应对绝大多数互联网业务的高并发读取。Redis 本质是一个基于内存的键值存储系统数据以 key-value 形式组织value 本身又支持多种数据结构。它之所以快不是因为它做了什么魔法而是因为数据常驻内存、读写不走磁盘再加上高效的事件驱动模型。这里要提醒一句快是快但不代表它可以无脑替代数据库它更适合做“高速通道”和“热点支撑”而不是持久化账本。1.2 该拿它做什么别拿它做什么说几个我实际项目中用得最多的场景正好也是面试高频点缓存加速、分布式会话共享、排行榜和计数器、分布式锁、简单的消息队列。比如用户登录态的会话信息放 Redis 里设置过期时间既能多节点共享又能自动失效再比如电商商品的浏览量用 incr 做原子计数性能远比数据库 update 高。反面的例子我也见过不少。有同事把全量商品数据倒进 Redis每天全量刷新内存占了几十 G冷数据浪费严重还有人用 Redis 做业务核心订单存储结果一宕机就丢数据。Redis 不是银弹把它定位成“加速层”和“协同层”比较合理数据源头仍然在业务数据库Redis 负责扛住高峰读流量和跨节点的状态共享。1.3 安装、可视化客户端与快速上手这一步很关键很多人卡在最开始的安装上。Windows 上做本地开发官方其实没有正式支持 Windows 版本的 Redis但可以用微软维护的旧版本或直接通过 Docker 跑这是目前最省事的方式。我在本地开发时基本用 Docker一条命令就能起来不用折腾编译环境版本切换也方便。如果你在 Linux 服务器上部署用 apt、yum 或者直接编译安装都可以不过建议优先用发行版仓库或官方提供的安装包方便后续升级。docker run -d --name redis --restartalways -p 6379:6379 redis:7.2光有服务端还不够日常调试总不能在命令行里一个命令一个命令敲。我最早用的是 Redis Desktop Manager后来项目里换成了 Another Redis Desktop Manager因为它的跨平台体验更稳定还能直接查看 key 的 TTL、内存占用和数据内容排查问题方便很多。装好客户端后连接时要注意配置好 host、端口和密码默认端口是 6379密码没设置虽然连得上但这在生产环境属于重大安全隐患后面会专门讲。2. 数据类型Redis真正厉害的地方2.1 String、Hash、List 背后的设计逻辑String 是最基础的但最容易被人低估。它不只是存字符串还支持数值自增自减比如 incr、decr、incrby这也是我后来排查业务 bug 的核心。很多人问“String 和 Hash 存对象选哪个”我的建议是如果对象字段访问密集、需要频繁修改某个字段用 Hash如果是整体序列化后一次性读写用 String 更省事。Hash 还有一个好处是类似关系型数据库的行开销比直接存一个很大的 JSON 字符串要小。List 在 Redis 里是双向链表适合做队列、栈和最新列表。比如我做过一个简单的异步通知队列用 LPUSH 写入、BRPOP 阻塞读取天然支持多消费者竞争。要注意的是List 基于链表实现在列表中间进行随机读写时性能一般如果需要按下标访问大量元素要考虑换成其他结构或者调整场景。2.2 Set、ZSet 和三个容易被忽略的高级结构Set 是无序集合常用在去重、交集并集计算。比如做共同好友、标签体系一条 SINTER 就能拿到交集比在数据库里写关联查询快得多。ZSet 则是有序集合每个元素带一个 scoreRedis 内部用跳跃表维护顺序排行榜、延时队列、按权重排序这些需求用 ZSet 写代码会很舒服。我做过一个直播间热度榜直接用 ZINCRBY 更新分数再 ZREVRANGE 取前几名几十万热度的场景下依然毫秒级返回。除了这五种基础类型还有 Bitmap、HyperLogLog、Geo 这几个高级结构面试时偶尔会考。Bitmap 适合标记类场景比如用户签到一个 bit 位代表一天内存极省。HyperLogLog 适合做基数统计比如 UV不用存每一个用户 ID误差可控能处理超大基数的去重统计。Geo 则是专门存经纬度和算距离的附近的人、门店配送范围这类功能可以直接用。2.3 序列化问题为什么你看到的是乱码这个坑几乎是新手必踩。用 Java 的 RedisTemplate 往 Redis 里写数据时如果不对 key 和 value 的序列化器单独配置默认用的 JDK 序列化会把对象转成一堆\xAC\xED\x00\x05t...之类的字节用可视化客户端一看就是乱码而且 key 里还可能带着奇怪的包名和类型信息。这不仅是难看的问题还会让你的 key 很难通过命令行精确删除甚至导致不同客户端写入的同一逻辑 key 对不上最终触发缓存命中率下降。我后来养成的习惯是RedisTemplate 中 key 统一用 StringRedisSerializervalue 用 Jackson 或 Fastjson2 序列化器Hash 的 key 和 value 也分别指定。这样写入的数据在可视化工具里可读跨语言、跨客户端也能互相操作。后面实战章节我会把 increment() 报错的完整排查过程写出来根子恰恰就在这里。3. 持久化RDB和AOF怎么选3.1 RDB快照看似简单其实要小心Redis 虽然主打内存但持久化能力绝不能忽略。RDB 是默认开启的持久化方式本质是生成某个时间点的全量内存快照存成一个 .rdb 文件。它恢复速度快、文件紧凑适合做冷备和容灾。但 RDB 有一个天然短板它是按时间点或条件触发保存的两次保存之间崩溃就会丢失这段时间的新写数据。比如 5 分钟一个快照崩溃时最多可能丢 5 分钟数据。这里面的技术细节是 fork 子进程生成快照主进程继续服务所以生成快照对线上读写影响不大。但在内存非常大的实例上fork 也有一定开销需要观察一下系统负载不要在大流量高峰反复触发 bgsave。还有一种反直觉的情况RDB 文件加载时 Redis 是阻塞的恢复一个几 GB 的 rdb 文件可能要停机几十秒甚至更久。所以生产环境的持久化选型通常不只是“开不开”的问题而是“怎么组合”的问题。3.2 AOF日志与混合持久化AOF 记录的是写指令本身配置成 everysec 每秒刷盘时最多丢失一秒数据可靠性比 RDB 高很多。但代价是文件体积大、恢复速度慢。好在 Redis 提供了 AOF 重写机制可以把日志压缩成尽量少的历史指令减少文件大小。真正让我推荐的是 Redis 后来引入的混合持久化AOF 重写后生成的文件先包含一份 RDB 内容再追加增量日志兼顾了 RDB 的恢复速度和 AOF 的数据安全性。这个组合是我在生产环境里最常用的方案。持久化配置要结合业务容忍度。如果是纯缓存场景数据丢了可以从数据库回源那可以完全关闭持久化获得更好的写性能如果是结算、库存这种强一致场景就不应该依赖 Redis 做最终保障该让数据库扛的还是要让数据库扛。我给多数项目的建议是开 AOF、appendfsync everysec、再开 RDB 作为兜底同时每天把 rdb 文件做异地备份。3.3 我实际使用的数据恢复流程这里给大家一个可以直接抄的恢复思路。假如 Redis 所在节点坏了先用 redis-check-rdb 和 redis-check-aof 检查备份文件是否完整然后把新的 Redis 实例启动好将备份文件放到配置的 dir 目录下调整好文件名重启实例Redis 启动时会自动加载。重点提醒恢复前一定要备份原文件不要在损坏的文件上直接覆盖。我踩过一次坑图省事直接用损坏的 rdb 启动结果 Redis 启动失败连排查的余地都没了。4. 高可用主从、哨兵、集群4.1 主从复制与读写分离单机 Redis 的可靠性再高也顶不住物理机故障所以生产环境至少要做主从。主节点负责写从节点负责读和备份数据通过异步复制同步过去。这个模式的优点是简单从节点挂了不影响主节点写入主节点挂了可以手动切换缺点是切换要人工介入做不到自动故障转移。配置主从时要注意不要让从节点承担写压力否则主从数据会不一致。当初我在 Docker 上搭主从时最容易被坑的是网络和配置。从节点连主节点时要确保主节点绑定的 IP 是日常客户端可访问的地址而不是 127.0.0.1有些镜像默认配置了保护模式不设密码时只允许本机访问会导致复制连不上。建议一开始就把密码统一配置好主从节点用同一套密码。配置正确后通过 info replication 可以看到 role 和连接状态这是我最常用的排查命令。4.2 哨兵模式自动故障转移主从复制解决了数据冗余但没有解决“主节点挂了怎么办”的问题。哨兵Sentinel就是专门来做监控和自动故障转移的它持续监控主从节点的健康状态发现主节点下线后会选举一个从节点提升为新主节点并通知客户端更新连接地址。我常说哨兵像是给 Redis 配了个值班员虽然它本身也要多部署几个节点防止单点但整体上比人工切换靠谱得多。配置哨兵最核心的是三个参数sentinel monitor 指定监控的主节点名称和地址sentinel down-after-milliseconds 判定下线的时间sentinel failover-timeout 控制故障转移超时。建议至少部署 3 个哨兵节点这样多数派才能正确判定主节点是否真的挂了避免脑裂。我之前遇到过只部署 1 个哨兵、主节点短暂网络抖动就被“误杀”的情况后来把哨兵数量提到 3 个并调大了误判阈值线上才稳定下来。4.3 Redis Cluster什么时候必须上集群当数据量超过单机内存、或者写并发单节点扛不住时就要考虑 Redis Cluster。Cluster 通过哈希槽把数据分布到多个主节点上共 16384 个槽每个主节点负责一部分每个主节点还能带从节点。客户端连接任意节点都能路由到正确位置。这样理论上可以横向扩展单节点的内存压力也降下来了。但集群不是完美的。多键操作比如跨节点的批量 mget、事务会受到限制除非这些 key 在同一个哈希槽里key 的迁移过程中也容易出现短暂的访问延迟。所以我给团队的建议是数据量和访问量没有明确到瓶颈前别盲目上集群先用好主从加哨兵通过合理分片逻辑和热点治理来省钱省心。上了集群后客户端选型也很重要像 Lettuce 和 Redisson 都支持集群模式需要专门配置节点地址列表。5. 分布式锁正确姿势与常见误区5.1 自己写锁的三个坑Redis 做分布式锁是经典场景但自己实现时坑极多。第一个坑是锁没有过期时间如果拿锁的进程在执行业务时突然宕机锁永远不释放其他线程全部阻塞。所以 SET key value EX 时间 NX 是必须的获取锁时就要带上过期时间。第二个坑是释放锁时没有校验持有者A 线程的锁过期后B 线程拿到了新锁A 线程执行完直接把锁删掉就把 B 的锁释放了导致并发问题。正确的做法是 value 存一个唯一标识删除前用 Lua 脚本判断是不是自己的锁。第三个坑是过期时间设置不合理。业务执行时间超过锁过期时间锁提前失效后面的线程就能趁虚而入。最简单的办法是设置足够长的过期时间并在业务结束后手动释放更严谨的做法是用“看门狗”续期机制也就是把过期时间不断延长直到业务执行完。我见过很多团队手搓锁最后都栽在这三个坑上所以我通常建议没有特殊原因直接引入 Redisson。5.2 Redisson不要重复造轮子Redisson 是一个基于 Redis 的 Java 客户端框架内置了可重入分布式锁、公平锁、读写锁、红锁等多种实现并且自带看门狗续期。它的使用体验非常贴近 JVM 里的 LocktryLock、unlock 接口一致团队上手成本很低。我一般在项目里引入 Redisson 后只需要配置好 Redis 连接然后注入 RedissonClient业务里直接用 RLock 就行完全不需要自己写 Lua 脚本。使用 Redisson 也有一些细节要注意。一是加锁和释放锁必须成对最好放到 finally 里防止异常时锁不被释放二是 Redisson 的 watchdog 默认 30 秒续期一次如果业务是长任务这个机制会显得格外有用三是锁的粒度要尽量细能用 key 维度的锁就别加载全表上否则性能依然会被拖垮。关于分布式锁还有一个老生常谈的问题Redis 主从架构下如果主节点在加锁后立刻宕机锁信息还没同步到从节点可能导致锁丢失。这个场景下需要 RedLock 算法但很多人争论它的有效性我的建议是先评估业务里是否能接受极小概率的重复执行如果完全不能接受就别依赖纯 Redis 方案考虑 ZooKeeper 或 etcd 这类强一致组件。6. 实战复盘RedisTemplate 的 increment() 报错排查6.1 问题现象有一次线上业务反馈有一个数字统计一直没更新查看日志发现大量报错ERR value is not an integer or out of range。这个错误出现在 RedisTemplate 调用 increment() 时按照我的经验第一反应会觉得是不是被写入的值不是纯数字或者超过了 Long 的范围。但排查下来value 本身明明是一个正常的数值型字符串数据库里的原始数据也是数字所以问题并不在业务代码的数值逻辑上。我当时的排查路径是先确认 Redis 里这个 key 的实际类型和值然后发现 key 本身看起来是正常的但 value 在可视化工具里显示成了不可读的字节内容。这就说明问题出在序列化层。用 RedisTemplate 默认的 JdkSerializationRedisSerializer 写入时整数值被包装成了 Java 序列化字节等再次调用 increment() 时Redis 服务端拿到的字符串并不是可解析的整数于是报 out of range 的错。6.2 根因序列化器不一致要彻底理解这个报错得先搞清楚 RedisTemplate 的组成。RedisTemplate 里有两套序列化器分别处理 key 和 value默认情况下 key、value、hashKey、hashValue 都用 JdkSerializationRedisSerializer。Jdk 序列化会把 Java 对象变成一段二进制字节流里面带着 Java 类型信息在 Redis 里作为一个整体字符串保存。incr 这类命令依赖 Redis 服务端把 value 当作十进制整数解析当 value 是一段 Jdk 序列化字节时自然解析失败。还有一个隐蔽点如果业务里一部分代码用了 RedisTemplate另一部分代码用了 StringRedisTemplate两者的序列化方式不一样往同一个 key 写的数据可能互相覆盖也会出现类似问题。StringRedisTemplate 默认就是 String 序列化对 incr 这类数值操作更友好。所以我在项目里定了两条规矩纯字符串或计数器场景统一用 StringRedisTemplate需要保存对象的场景自定义 RedisTemplate但 key 必须用 StringRedisSerializervalue 用 JSON 序列化器。6.3 修复后的完整配置修复方式其实不复杂。要么把计数这类操作统一改成 StringRedisTemplate 调用 increment()同时确保这个 key 之前没有被 Jdk 序列化器污染要么自己重新定义 RedisTemplate替换默认的序列化器。我贴一个实际项目中常用的配置思路新建一个 RedisConfig 类定义 Bean 时设置 keySerializer 为 StringRedisSerializervalueSerializer 用 GenericJackson2JsonRedisSerializer如果对字符串可读性要求极高也可以直接用 StringRedisTemplate 处理计数器对象场景再用自定义 template。Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer keySerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer valueSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(keySerializer); template.setHashKeySerializer(keySerializer); template.setValueSerializer(valueSerializer); template.setHashValueSerializer(valueSerializer); template.afterPropertiesSet(); return template; }改完配置后一定要先删除旧 key 或换一个测试 key因为已经被写入的错误数据不会自动修复回源重新缓存一次才彻底干净。我也总结过这类问题的时间成本大部分 Redis 使用异常都不是命令语法错了而是序列化规则不统一造成的。所以在团队里我要求所有接入 Redis 的模块统一使用同一套序列化规范避免不同模块各写各的把问题从源头掐断。7. 日志、安全加固与升级7.1 日志怎么看Redis 日志文件默认配置在 redis.conf 的 logfile 中常用级别有 debug、verbose、notice、warning。生产环境建议开到 notice 以上否则每秒钟的读写操作会刷爆日志文件。排查问题时先看启动日志是否正常再看慢查询日志配置 slowlog-log-slower-than 后通过 SLOWLOG GET 可以看到哪些命令执行时间过长。这在定位大 key、热 key 问题时特别有用。还要提醒一点不要在生产环境长时间开着 MONITOR 命令它会打印所有命令瞬间消耗大量 CPU。7.2 未授权访问与安全加固Redis 默认配置下如果不做任何保护监听在公网 IP 上且没有密码后果会很严重。我见过不少因为未授权访问被恶意写入数据的案例所以安全加固必须当成上线前的基础项。首先要设置 requirepass而且密码要足够复杂其次要修改 bind 配置只监听内网地址不要直接暴露到公网还可以通过 rename-command 禁用危险命令比如 CONFIG、EVAL 等。千万别觉得“内网环境很安全”一旦旁路被攻破内网横向移动时 Redis 就是最容易下手的目标之一。另外如果使用 Docker 部署 Redis端口映射不要随意写成 0.0.0.0:6379最好只映射到内网网卡并且容器网络尽量使用自定义网络而非 host 模式。日志里也要经常关注异常连接配合防火墙和云安全组做白名单限制。我在团队里专门整理过一份上线检查清单Redis 部分包括是否设置密码、bind 是否合理、危险命令是否禁用、是否开启了持久化、最大内存是否配置、淘汰策略是否明确。7.3 版本选择与升级建议Redis 版本更迭很快很多人装的是老版本遇到内存碎片问题或数据一致性问题时很难排查。我建议新项目直接使用 7.x 版本比如 7.0、7.2它们引入了不少性能优化和新特性比如更好的内存管理、函数特性整体稳定性也更高。如果线上是老版本升级前一定要先看 release notes重点检查废弃命令和数据格式兼容性。升级步骤一般是先搭一套新版本环境做一次数据迁移和压测再灰度切换流量不要在高峰期直接升级。Windows 上本地开发的话可以用 Redis 官方在 Windows 上的移植版或者 Docker 镜像但生产服务器我强烈建议用 Linux。很多 Windows 版本内核较老缺少 Linux 上的高并发优化在线下演示没问题上生产容易踩坑。如果是 ARM 架构服务器可以拉对应的 ARM 镜像或从源码编译注意不要拿错 amd64 的安装包。8. 常见问题速查表我在不同的团队里处理过不少 Redis 使用问题下面这张表基本覆盖了日常高频故障遇到问题可以先对号入座再针对性排查。现象大概率原因解决思路incr/decr 报 ERR value is not an integer序列化器造成 value 内容不是纯数字改用 StringRedisTemplate 或统一 key/value 序列化器清理旧 key可视化客户端看到乱码使用了 JDK 默认序列化器自定义 RedisTemplate 的 key/value 序列化器连接不上 Redisbind、保护模式、防火墙、密码错误检查绑定地址、requirepass、安全组确认端口主从复制失败主节点绑定了 127.0.0.1、无密码保护模式使用内网 IP 绑定统一配置密码缓存雪崩大量 key 同一时间过期过期时间加入随机偏移多级缓存兜底缓存穿透查询不存在的数据每次都打到 DB布隆过滤器或缓存空对象大 key 导致慢查询一个 key 值过大序列化或传输耗时拆分 key、压缩 value使用 SCAN 定位热 key 使单节点 CPU 高热点数据集中本地缓存、key 加随机后缀分片读这张表看起来简单但每一条背后都对应过真实线上事故。我自己的体会是Redis 用的不是花哨而是规范和预案。序列化规则定好、过期时间设计好、主从哨兵搭到位、安全加固做扎实大部分问题都能在萌芽阶段被拦住。最后分享一个实际运维中的小技巧给 Redis 配置 maxmemory 和合理的淘汰策略比如 allkeys-lru会比让它无限使用物理内存安全得多操作之前养成先 SCAN 而不是 KEYS 的习惯尤其在生产环境一条 KEYS * 就足够把实例打挂。把基础习惯养成Redis 就会成为项目里最省心的组件之一。
