部署在EC2的STANDALONE版Redis存600万key后每日宕机2次，是什么原因？

• 内存溢出触发OOMKill：600万key的总内存占用如果超过EC2实例的物理内存+swap阈值，Linux内核会主动杀掉内存占用最高的Redis进程，这是单机Redis大数据量场景下最常见的宕机原因。你可以通过dmesg | grep -i oom命令确认是否存在OOM日志。
• 持久化触发fork阻塞：当Redis开启RDB/AOF持久化时，fork子进程的内存开销是当前Redis内存占用的1:1（写时复制机制生效前），如果实例剩余可用内存不足以支撑fork操作，要么fork失败停止服务，要么触发OOM。另外大key的持久化写入也会导致磁盘IO打满，阻塞Redis主进程触发宕机。
• 过期键淘汰策略配置不合理：如果Redis设置了maxmemory但淘汰策略不合适，或者未设置maxmemory，内存占满时要么拒绝写入，要么触发OOM。另外大量键设置了相同的过期时间，集中过期时的清理逻辑会阻塞主进程，导致服务不可用甚至宕机。
• EC2实例资源限制：如果使用的是突发性能实例（t系列），CPU积分耗尽后实例性能被限制到基线以下，无法支撑Redis的高并发请求/持久化操作，导致请求堆积最终服务崩溃。也有可能是EC2的磁盘IOPS达到上限，持久化写入超时触发Redis崩溃。
• 大key/热key资源耗尽：如果存在单个value超过100KB的大key，或者单key每秒请求量超过1万的热key，在600万key的量级下很容易打满CPU/内存带宽，导致主进程阻塞宕机。你可以用redis-cli --bigkeys和redis-cli --hotkeys命令扫描确认。

紧急修复措施 #

• 执行dmesg | grep -i oom确认是否为OOMKill导致，如是首先调整Redis的maxmemory参数，设置为实例物理内存的70%以内，同时配置合理的内存淘汰策略，比如maxmemory-policy allkeys-lru，优先淘汰最少访问的键，避免内存占满。
• 临时关闭RDB/AOF持久化确认是否还会宕机，如果关闭后恢复正常，说明是持久化导致的问题，可以调整持久化触发阈值，比如把RDB的触发条件从save 900 1改成更高的阈值，或者只在业务低峰期执行手动RDB备份。
• 查看EC2实例监控，如果是CPU积分耗尽/IOPS达到上限，直接升级实例规格，优先选择内存优化型实例（r系列），搭配高IOPS的GP3或者io2 EBS卷。

长期优化措施 #

• 拆分大key：将单个大value拆分成多个小key存储，避免大key的读写/持久化占用过多资源。
• 调整过期键设置：如果存在大量同时过期的键，给每个键的过期时间加上1-300秒的随机偏移，避免集中过期阻塞主进程。
• 开启Redis的lazy free机制：配置lazyfree-lazy-eviction yes、lazyfree-lazy-expire yes、lazyfree-lazy-server-del yes，让过期键删除、淘汰键删除等操作走异步线程，不阻塞主进程。
• 替换单机部署为集群模式：如果业务量还在持续增长，后续可以切换为Redis Cluster集群架构，将数据分片到多个节点，分散单节点的内存/CPU压力，避免单节点故障导致整体服务不可用。
• 增加监控告警：配置Redis的内存使用率、CPU使用率、持久化耗时、OOM事件等监控指标，阈值触发时提前告警，避免等到服务宕机才处理。

内容的提问来源于stack exchange，提问作者krishnakumar Balasubramaniam