定时任务单线程消费 redis 中数据导致消费能力不足
问题描述
大年初一，收到报警通知，Redis 机器内存使用率已经超过 90%，达到了危险值。Redis 管理同学反馈这一情况，希望尽快处理以避免系统崩溃或性能严重下降
处理流程
- 反馈直接上级
拉群并简要说明问题：第一时间在工作群里通知直接上级和其他相关同事，简要说明 Redis 内存使用率过高，已经达到危险值，需要紧急处理
初步沟通解决方案：询问是否有紧急处理方案，以便快速响应 - 排查问题
排除新需求导致的问题：春节期间没有新需求上线，排除新需求导致的问题
定位问题原因：需要确定是哪个 key 占用了大量内存，或者哪个业务流程导致了内存使用率过高 - 获取 Redis 占用信息
询问 Redis 同学：由于不熟悉公司提供的 Redis 客户端，直接联系 Redis 管理同学，请求提供内存占用较大的 key 信息
获取反馈：Redis 同学很快提供了内存占用表：
- 最大的字符串 key ‘xxxxxx1’ 占用了 1055839 字节
- 最大的列表 key ‘xxxxxx2’ 包含 13518155 个元素
- 分析业务流程
定位关键业务：‘xxxxxx2’ 列表过大，需要分析其相关的业务流程
业务流程：接收上游 Kafka 消息，将收到的数据转换成 POJO 存入 Redis，然后通过定时任务消费 Redis 中的数据。定时任务是单点执行的
问题原因：上游消息太多，消费速度跟不上，导致 Redis 内存占用过高 - 解决方案
减少接收上游消息：会丢弃消息，需要变更代码并上线，风险较大，暂时不考虑
增加 Kafka 消费速度：需要变更代码并上线，审批流程复杂，风险较高，暂时不考虑
临时手段：修改代码，使定时任务多线程消费 Redis 中的数据，加快消费速度
实施步骤：
- 修改代码，使定时任务多线程消费 Redis 数据
- 在灰度环境上线修改后的代码
- 停止线上定时任务，确保灰度环境中的代码能够正常运行
- 观察数据消费情况，确保问题得到解决
- 观察效果
监控数据：观察 Redis 内存使用率和数据消费情况，确保问题得到有效解决
恢复线上任务：确认灰度环境中的代码运行稳定后，逐步恢复线上定时任务
总结
1，本次问题是由于 Redis 内存使用率过高导致的，主要原因是上游消息量大，消费速度跟不上
2，虽然问题本身并不复杂，但由于发生在非窗口期（春节期间），需要紧急变更代码，增加了处理难度。还有需要及时向上级反馈问题，并与 Redis 管理同学紧密合作，快速获取关键信息，制定并实施了有效的临时解决方案
3，未来应加强对 Redis 内存使用情况的监控，提前发现潜在问题