跳到正文
Redis运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 11
个案例。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 36
期｜redis集群扩容问题分析
- 专辑文件：
06.html，第 7 个案例
- 查看原文
- 现象： redis集群扩容。
- 处置过程：
新主机新节点依次加入集群成为主节点；cluster add-node x.x.x.x:x x.x.x.x:x
-a $passwd；新主机新节点依次加入集群成为主节点的从节点
- 运维建议：
提前规划好主从节点映射，计算好平衡需要花费的时间。
第 36 期｜redis
业务侧反应慢问题分析
- 专辑文件：
06.html，第 8 个案例
- 查看原文
- 现象： xxxx项目，业务侧反应慢。
- 处置过程： 业务侧使用的是通过；kem
部署的redis集群，3主3从模式，进入到redis的pod里面，通过命令cluster
info检查redis集群状态正常，执行 cluster nodes
检查3主3从节点也正常。；登录redis cluster 3个主节点中，发现大量的slowlog
都是关于固定的key，排查redis 相关pod的监控，发现redis
每秒处理的命令数超过5000，且使用的cpu 已经到达99%。
- 运维建议： 添加了一个init pod；echo never
>/sys/kernel/mm/transparent_hugepage/enabled；的作用是禁用透明大页功能
第 30
期｜redis查询报错问题分析
- 专辑文件：
12.html，第 8 个案例
- 查看原文
- 现象： redis查询频繁报错；“(error)LOADING Redis is
loading the dataset in memory”；，查询失败。
- 处置过程：
这套redis集群三主三从，定位到只有一从节点出现查询报错，怀疑是节点主从同步方面的问题。；链接到从节点上，info命令查询redis运行信息，尤其注意主从状态是否正常，查询到从节点的；master_link_status:
down
- 运维建议： 先查看redis
info，查看是否有异常值，然后再根据报错日志网上搜索。使用config
set命令后，下次重启会失效。
第 30
期｜redis内存以及key持续增涨问题分析
- 专辑文件：
12.html，第 9 个案例
- 查看原文
- 现象： MOA-redis85内存以及key持续大幅增涨。
- 处置过程： 登录库查看占用内存情况；info
memory发现内存占用偏高。；查看key数量
- 运维建议：
未设置合适的ttl过期时间｜减少不必要的内存占用并提高查询效率；默认淘汰策略为noeviction｜达到内存限制时自动移除部分键，防止内存溢出；第三方系统代码上存在循环更新错误逻辑，五分钟就会更新200万条数据一直推送异常数据，kafka消费异常
第 30
期｜redis读写延时较高问题分析
- 专辑文件：
12.html，第 10 个案例
- 查看原文
- 现象：
大数据业务侧反馈有一套redis读写延时；经检查3台redis主机1台操作系统为BigCloud；（该主机2024年6月进行了国产化改造）
- 处置过程：
检查主机资源使用情况；发现主节点io存在写入排队情况。；分析reids日志
- 运维建议：
国产化改造主机；（BigCloud）；因内核、文件系统或驱动差异，导致Redis数据同步失败增加主节点性能消耗，redis集群国产化改造应按照集群为单位进行
第 28
期｜redis组件中特殊字符key名冲突导致服务无法启动
- 专辑文件：
14.html，第 9 个案例
- 查看原文
- 现象：
千人千面redis集群7015节点服务退服。排查日志发现是内存溢出导致的服务退服，后直接恢复服务一直报内存错误无法恢复。
- 排查与原因：
通过检查发现故障节点的的存储数据是其它节点的2-3倍，总存储在接近16G，且存在大量的大KEY，单个key大小达到了2G以上。；每次启动都是报的相同key触发了bug。；解析rdb文件发现这个特殊key有两个。
- 处置过程：
业务整改大key问题，避免导致单个服务的存储过高导致数据分布不均。；直接del删除空字符key。（无法删除）；计划将空字符key迁移到其它槽。（无法定位到具体槽位）
- 运维建议： 制定严格的Redis
KEY命名规范；本次故障中，特殊字符KEY名是导致服务无法启动的重要原因之一。因此，在未来的Redis使用中，应严格避免使用特殊字符作为KEY名。这不仅可以避免潜在的bug和兼容性问题，还可以提高系统的稳定性和可维护性。；特殊字符在Redis的KEY名中可能导致解析错误、无法删除或迁移等问题。此外，特殊字符还可能影响Redis的性能和稳定性，增加系统的维护成本。
第 18 期｜redis
从节点内存使用率异常分析
- 专辑文件：
24.html，第 3 个案例
- 查看原文
- 现象：
哨兵模式，从节点内存使用率超过80%，但是主节点内存使用率正常。
- 处置过程： 检查物理内存一样大；info
memory；used_momory_human不一样大。
- 运维建议：
注意观察启动时间等指标；集群的启动需要按照规定流程实施；建立有效的监控系统，监控Redis从节点的内存使用率，并设置报警阈值
第 8 期｜REDIS故障处置
- 专辑文件：
34.html，第 8 个案例
- 查看原文
- 现象：
底层交换机故障切换引起的网络波动导致应用连接redis出现超时问题，出现用户app和维护web后台使用异常，报错redis连接超时异常。
- 排查与原因：
通知排查redis集群（proxy集群），集群显示正常后，日志中仍有redis连接超时的报错。；对主流程的服务进行重启后恢复。；反馈底层接入交换机故障，备机切换到主机过程中，部分流量转发异常，切换时间耗时
25 秒，导致负载到该接入设备的业务访问出现异常。
- 处置过程： 通过LTS日志服务查看redis timed
out报错信息。
- 运维建议：
针对断连存在异常问题，给出的是使用jedis替换lettuce连接池，原因是Lettuce异常的连接无法通过命令进行探测，使用异常连接发起请求会造成业务超时，重试后重建连接恢复。Jedis连接池可以通过配置借用前连接探测，屏蔽异常连接对于业务的影响。；由于spring
boot2.0默认redis连接池采用lettuce，Lettuce客户端基于Netty的NIO框架实现，性能较较好，因此，开发人员对lettuce连接池进行二次封装，增加对redis服务探活，保证连接池的连接可用性。；加强监控角度，对主流程服务添加
error，timed out的关键字日志监控
第 6
期｜业务系统访问redis服务器报异常及内存溢出
- 专辑文件：
36.html，第 2 个案例
- 查看原文
- 现象：
业务侧反馈某业务侧访问redis集群服务器异常，且应用程序抛出内存日常错误。；2.
处置方案；根绝业务侧提供的报错第一时间排查了redis主节点日志，发现无明显报错信息。
- 运维建议：
初始配置redis集群时，分配的redis最大内存使用量不宜过小，配置为系统可用内存的50%-70%。；redis监控告警可添加used_memory_human|used_memory_peak_human指标。
第 4
期｜Redis因内存用满导致服务异常处置
- 专辑文件：
38.html，第 8 个案例
- 查看原文
- 现象：
基线服务redis保存周期默认一百天，导致redis所在机器内存过大、持久化后导致磁盘打满，无法写入。；2.
处置方案；关停redis服务；
- 运维建议：
基线服务redis保存周期由100天改为1天。修改application.baseline.item-history-data-redis-expire-day=100
为1。
第 3 期｜REDIS数据库时快时慢
- 专辑文件：
39.html，第 1 个案例
- 查看原文
- 现象：
时慢时快Redis集群：9台物理主机一主两从配置，共405个节点；；2）业务规则；通过spark访问redis取全省数据做计算，数据量都在千万级以上。
- 处置过程： 2.1 edis指标复核；master
node实时并发访问300+；；Redis基准性能测试最高延迟0.2ms；
- 运维建议：
随着开源软件，开源数据库的引入，在提升效率降低成本的同时，也增加了系统运行稳定性的风险，需要引入最佳实践落地，而最佳实践往往需要通过规模化，通过无数的踩坑才能形成避坑指南，我们可以充分利用他山之玉。