# Redis运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **11 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 36 期｜redis集群扩容问题分析](#case-1)
- [第 36 期｜redis 业务侧反应慢问题分析](#case-2)
- [第 30 期｜redis查询报错问题分析](#case-3)
- [第 30 期｜redis内存以及key持续增涨问题分析](#case-4)
- [第 30 期｜redis读写延时较高问题分析](#case-5)
- [第 28 期｜redis组件中特殊字符key名冲突导致服务无法启动](#case-6)
- [第 18 期｜redis 从节点内存使用率异常分析](#case-7)
- [第 8 期｜REDIS故障处置](#case-8)
- [第 6 期｜业务系统访问redis服务器报异常及内存溢出](#case-9)
- [第 4 期｜Redis因内存用满导致服务异常处置](#case-10)
- [第 3 期｜REDIS数据库时快时慢](#case-11)
## 第 36 期｜redis集群扩容问题分析
- 专辑文件：`06.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** redis集群扩容。
- **处置过程：** 新主机新节点依次加入集群成为主节点；cluster add-node x.x.x.x:x x.x.x.x:x -a $passwd；新主机新节点依次加入集群成为主节点的从节点
- **运维建议：** 提前规划好主从节点映射，计算好平衡需要花费的时间。
## 第 36 期｜redis 业务侧反应慢问题分析
- 专辑文件：`06.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** 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 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** 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 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** MOA-redis85内存以及key持续大幅增涨。
- **处置过程：** 登录库查看占用内存情况；info memory发现内存占用偏高。；查看key数量
- **运维建议：** 未设置合适的ttl过期时间｜减少不必要的内存占用并提高查询效率；默认淘汰策略为noeviction｜达到内存限制时自动移除部分键，防止内存溢出；第三方系统代码上存在循环更新错误逻辑，五分钟就会更新200万条数据一直推送异常数据，kafka消费异常
## 第 30 期｜redis读写延时较高问题分析
- 专辑文件：`12.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** 大数据业务侧反馈有一套redis读写延时；经检查3台redis主机1台操作系统为BigCloud；（该主机2024年6月进行了国产化改造）
- **处置过程：** 检查主机资源使用情况；发现主节点io存在写入排队情况。；分析reids日志
- **运维建议：** 国产化改造主机；（BigCloud）；因内核、文件系统或驱动差异，导致Redis数据同步失败增加主节点性能消耗，redis集群国产化改造应按照集群为单位进行
## 第 28 期｜redis组件中特殊字符key名冲突导致服务无法启动
- 专辑文件：`14.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562405&idx=1&sn=5764e321cddf8d027678d4f3c4236f63&chksm=f8a25ac12867bf0f378586a0e275e57117dc193c1d28f6df10c196bf48cf0e5a4ac5a7ebede2#rd)
- **现象：** 千人千面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 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** 哨兵模式，从节点内存使用率超过80%，但是主节点内存使用率正常。
- **处置过程：** 检查物理内存一样大；info memory；used_momory_human不一样大。
- **运维建议：** 注意观察启动时间等指标；集群的启动需要按照规定流程实施；建立有效的监控系统，监控Redis从节点的内存使用率，并设置报警阈值
## 第 8 期｜REDIS故障处置
- 专辑文件：`34.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** 底层交换机故障切换引起的网络波动导致应用连接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 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247547362&idx=1&sn=e81f89caa975c5168690b4aaa64a34e3&chksm=f8214034dc2cdac26f9fcee01a8c4389ddf22c0fdb982fb6b71d6397e4bb9a3a3d2fba160f78#rd)
- **现象：** 业务侧反馈某业务侧访问redis集群服务器异常，且应用程序抛出内存日常错误。；2. 处置方案；根绝业务侧提供的报错第一时间排查了redis主节点日志，发现无明显报错信息。
- **运维建议：** 初始配置redis集群时，分配的redis最大内存使用量不宜过小，配置为系统可用内存的50%-70%。；redis监控告警可添加used_memory_human|used_memory_peak_human指标。
## 第 4 期｜Redis因内存用满导致服务异常处置
- 专辑文件：`38.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** 基线服务redis保存周期默认一百天，导致redis所在机器内存过大、持久化后导致磁盘打满，无法写入。；2. 处置方案；关停redis服务；
- **运维建议：** 基线服务redis保存周期由100天改为1天。修改application.baseline.item-history-data-redis-expire-day=100 为1。
## 第 3 期｜REDIS数据库时快时慢
- 专辑文件：`39.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** 时慢时快Redis集群：9台物理主机一主两从配置，共405个节点；；2）业务规则；通过spark访问redis取全省数据做计算，数据量都在千万级以上。
- **处置过程：** 2.1 edis指标复核；master node实时并发访问300+；；Redis基准性能测试最高延迟0.2ms；
- **运维建议：** 随着开源软件，开源数据库的引入，在提升效率降低成本的同时，也增加了系统运行稳定性的风险，需要引入最佳实践落地，而最佳实践往往需要通过规模化，通过无数的踩坑才能形成避坑指南，我们可以充分利用他山之玉。