案例分享,由于研发的代码逻辑问题,导致redis内存急速飙升
群582337768分享的一个实际案例
由于研发的逻辑处理不当,导致内存急速飙升。
ps: 研发排查了N天,没查出来,群友三下五除二就搞定了。你确定不加一下吗
研发【想法】的代码逻辑-客户端请求:
-
请求处理逻辑:
- 如果redis有数据,就在redis进行查询。
- 如果Redis中没有数据,则在MySQL中进行查询,并将结果插入Redis以供后续使用。
-
内存激增问题【客户端节点数量多】:
- 【qps其增】客户端请求内容需要更新同一个Redis key,导致在高并发情况下可能出现内存激增。
- 【暂存】需要保证数据一致性,将客户端请求内容先保存到Redis的某个“暂存区”。
- 【统一】暂存区的数据需依次更新同一个Redis key的内容。
- 【增加】由于暂存区数据不释放,导致内存持续增加。
- 【单key内容超过250K,只能表示他们真的250吧】注意到单个key内容超过250K时,需评估是否有必要对单个key的数据进行拆分,以避免内存压力。
解决方向的选择:
- 获取锁【SETNX分布式锁,谁有锁谁有写的权限】:
- 使用分布式锁机制,确保只有一个程序能进行写入操作,其他程序需等待。
- 需要考虑锁的粒度、超时机制及死锁情况的处理,确保系统健壮性。
- Redis内存管理【redis的内存碎片和内存波动】:
- 监控Redis的内存碎片和波动问题,确保内存使用效率。
- 可以使用Redis的内存管理工具,定期清理不必要的数据,设置合理的TTL(过期时间)以自动释放内存。
- 数据一致性:
- 在高并发情况下,考虑使用乐观锁或其他一致性机制,确保数据的准确性和一致性。
- 性能优化:
- 考虑Redis的分片或集群方案,以应对高QPS环境下的性能瓶颈,提升整体系统的可用性和响应速度。