问题描述

大年初一，收到报警通知，Redis 机器内存使用率已经超过 90%，达到了危险值。Redis 管理同学反馈这一情况，希望尽快处理以避免系统崩溃或性能严重下降

处理流程

1. 反馈直接上级 拉群并简要说明问题：第一时间在工作群里通知直接上级和其他相关同事，简要说明 Redis 内存使用率过高，已经达到危险值，需要紧急处理 初步沟通解决方案：询问是否有紧急处理方案，以便快速响应
2. 排查问题 排除新需求导致的问题：春节期间没有新需求上线，排除新需求导致的问题 定位问题原因：需要确定是哪个 key 占用了大量内存，或者哪个业务流程导致了内存使用率过高
3. 获取 Redis 占用信息 询问 Redis 同学：由于不熟悉公司提供的 Redis 客户端，直接联系 Redis 管理同学，请求提供内存占用较大的 key 信息 获取反馈：Redis 同学很快提供了内存占用表：

• 最大的字符串 key 'xxxxxx1' 占用了 1055839 字节
• 最大的列表 key 'xxxxxx2' 包含 13518155 个元素

4. 分析业务流程 定位关键业务：'xxxxxx2' 列表过大，需要分析其相关的业务流程 业务流程：接收上游 Kafka 消息，将收到的数据转换成 POJO 存入 Redis，然后通过定时任务消费 Redis 中的数据。定时任务是单点执行的 问题原因：上游消息太多，消费速度跟不上，导致 Redis 内存占用过高
5. 解决方案 减少接收上游消息：会丢弃消息，需要变更代码并上线，风险较大，暂时不考虑 增加 Kafka 消费速度：需要变更代码并上线，审批流程复杂，风险较高，暂时不考虑 临时手段：修改代码，使定时任务多线程消费 Redis 中的数据，加快消费速度 实施步骤：

• 修改代码，使定时任务多线程消费 Redis 数据
• 在灰度环境上线修改后的代码
• 停止线上定时任务，确保灰度环境中的代码能够正常运行
• 观察数据消费情况，确保问题得到解决

6. 观察效果 监控数据：观察 Redis 内存使用率和数据消费情况，确保问题得到有效解决 恢复线上任务：确认灰度环境中的代码运行稳定后，逐步恢复线上定时任务

总结

1，本次问题是由于 Redis 内存使用率过高导致的，主要原因是上游消息量大，消费速度跟不上 2，虽然问题本身并不复杂，但由于发生在非窗口期（春节期间），需要紧急变更代码，增加了处理难度。还有需要及时向上级反馈问题，并与 Redis 管理同学紧密合作，快速获取关键信息，制定并实施了有效的临时解决方案 3，未来应加强对 Redis 内存使用情况的监控，提前发现潜在问题