目录
1、内存上限介绍
1.1、产生原因
1.2、Redis的maxmemory限额
1.3、影响的命令与场景
2. 内存用完后的策略
2.1、淘汰策略分类
2.2、淘汰策略介绍
2.3、不同策略对比
3、常见业务示例
3.1、影响
3.2、监控与自动告警
前言
在日常项目中，不知道你思考过没有redis的内存耗尽的情况？
如下所示：
具体行为：
当内存满时：
- 读操作（如GET）：可以正常进行
- 写操作（如SET、LPUSH、SADD等）：
- 如果能通过淘汰策略释放一点空间，则写入继续
- 如果根据策略无法再释放空间（比如noeviction），则直接返回错误：“OOM command not allowed when used memory > 'maxmemory'.”
风险：
- 如果是noeviction（默认），Redis直接拒绝写入！
- 如果淘汰策略被触发，你的“旧数据”就会被自动删除（可能有业务风险）。
- 内存页碎片、fork快照等也会加速内存耗尽。
- 极端情况下，如果宿主机内存被撑爆，系统可能直接kill掉Redis进程（OOM Killer）。
关于更多redis的介绍，可参考：对Redis组件的深入探讨_redis 磁盘 内存-CSDN博客文章浏览阅读1.3k次，点赞20次，收藏8次。前言在介绍redis的时候，先介绍下存储介质，磁盘和内存。通过对以下两种认识，对了解redis有着更深的理解。如下图所示：以上就是r。_redis 磁盘 内存https://blog.csdn.net/weixin_50055999/article/details/147757520?spm=1011.2415.3001.5331
1、内存上限介绍
Redis是内存数据库，所有数据(Key/Value)都存放在内存（RAM）中，不像MySQL等主要用磁盘。
Redis的数据结构不仅要存储你的 key/value 数据，还要存储：
1、Key/value 相关的元数据（如过期信息）
2、Append Only File (AOF)
3、缓冲区复制缓冲区、客户端连接缓冲区等
所以实际内存消耗 = 数据+各种维护数据+内存碎片。
1.1、产生原因
1、数据总量超过maxmemory配置：
这是最常见情况：写入、缓存、业务量上涨、没有删除机制，累计到了上限。
2、未设置maxmemory，Redis自动用光了系统全部内存：
系统会自动kill Redis进程（Linux OOM Killer）。
3、AOF或RDB备份引起内存瞬时暴涨：
快照/流复制/fork过程占用大量额外内存。
4、客户端缓冲区、复制缓冲区太大：
有些命令或者慢客户端导致缓冲区堆积。
5、内存碎片率很高：
内存并不是100%利用，碎片率过高也会导致出现“看似还有容量，实际已用尽”的问题。
1.2、Redis的maxmemory限额
Redis 是基于内存的数据库，其总内存上限可通过maxmemory参数配置。
比如在redis.conf中：
maxmemory 1gb
如果你没有设置，理论上 Redis 可以用光宿主机所有可用内存，直到被Linux OOM杀死进程。
1.3、影响的命令与场景
1、影响所有产生新内存分配的命令
包括：set/hash/set/zset/list的增量写入命令，bitmap、hyperloglog…
2、以下命令不会报错
读命令(GET/EXISTS/SCAN等)
删除命令（DEL/EXPIRE/UNLINK）
清空命令（FLUSHDB、FLUSHALL）
2. 内存用完后的策略
当 Redis 达到 maxmemory 限制（即内存“用完”），会按照配置的淘汰策略（maxmemory-policy参数）来处理新写入命令。
如下图所示：
写请求 -> 检查used_memory|是否超maxmemory?/ \否 是| |正常写 执行淘汰策略|能释放内存吗？/ \能 不能| |正常写 返回OOM错误，写失败
2.1、淘汰策略分类
- noeviction（默认）：不淘汰，拒绝写入，只允许读；
- allkeys-lru：将所有key中最久未使用的key淘汰；
- volatile-lru：只对设置了过期时间的key做lru淘汰；
- allkeys-random：所有key随机淘汰；
- volatile-random：只对设置了过期的key随机淘汰；
- volatile-ttl：优先淘汰过期时间到期最早的key；
- volatile-lfu、allkeys-lfu：最不常用的（Least Frequently Used）key被淘汰。
2.2、淘汰策略介绍
1、noeviction（默认）
只读不写： 所有新增key、修改key、增加元素的命令（如SET、LPUSH、HSET等） 统统返回错误（error），只允许读（GET等）。
(error) OOM command not allowed when used memory > 'maxmemory'.
- 危险：
- 业务写入完全中断
- 可能造成数据库/队列/秒杀等核心数据业务丢失
- 生产极其危险，尤其是做缓存穿透时容易击穿下游数据库
2、allkeys-lru
自动淘汰：
优先淘汰“最久未使用”的key（Least Recently Used），腾出空间让新数据写成功。
风险：
部分“冷数据”被自动删掉，新数据继续写入，服务不中断，但有可能丢掉了有用的老数据。
3、volatile-lru
- 只判断有过期时间（expire）的key。
- 只淘汰带过期时间的key，不带过期属性的key永远不会被删
- 如果全是永久key，效果跟noeviction一样，容易写不进去
4、allkeys-random/volatile-random
- allkeys-random：任意key随机淘汰。
- volatile-random：也只淘汰带过期的key，随机选择。
5、volatile-ttl
只淘汰带过期时间里“快要到期”的key。
6、allkeys-lfu/volatile-lfu
淘汰最少被访问的key（Least Frequently Used），更智能。
2.3、不同策略对比
如下所示：
注意：
- 持久化（RDB/AOF）也有可能被影响，如果没法持久化新数据，有可能异常或数据丢失！
- 主从同步、集群等同步数据也受maxmemory影响。
3、常见业务示例
3.1、影响
1、缓存：
如果用作普通缓存，可以用allkeys-lru/allkeys-lfu让Redis自动“以空间换时间”。热点数据永远在，冷数据慢慢淘汰，更健康。
2、持久化队列/核心计数/实时业务：
如果Redis用作数据库功能（存放业务数据、消费队列），noeviction策略推荐。避免关键数据被误删。一旦写入超限应报警、扩容、限流，绝不随便丢“老数据”。
3、大key、热key、慢客户端
某个大key占住大量内存，会加速爆表，需依据业务定期分析优化。
更多bigkey文章介绍，参考：
Redis中的bigkey的介绍及影响_redis 大key-CSDN博客文章浏览阅读1.2k次，点赞31次，收藏12次。什么是BigKey？为什么它成为Redis的性能杀手？BigKey指在Redis中key对应的value占用内存或元素数量超出业务合理阈值的键值对。_redis 大keyhttps://blog.csdn.net/weixin_50055999/article/details/148856033?spm=1011.2415.3001.5331
4、内存暴涨瞬间写崩溃
新增了超大key（如bitmap、大string、大list），远超单条key的预期，会导致写入命令的突然异常或长时间阻塞（尤其fork的时候）。
3.2、监控与自动告警
建议配合运维/监控工具（如Prometheus、Grafana、redis_exporter、阿里云/腾讯云云监控等）。
重点关注：
1、used_memory (info memory)。
2、maxmemory。
3、内存碎片率。
4、淘汰计数器evicted_keys。
5、命令拒绝计数rejected_connections。
总结
Redis的内存满了，不同的淘汰策略决定要不要丢弃已有数据腾空间，否则直接拒绝写入并报错，只能读不能写，业务必须配合好监控、限流和数据结构优化。
参考文章：
1、内存耗尽后，Redis会发生什么？_redis中key没有达到过期时间,但是内存满了会怎么样?-CSDN博客文章浏览阅读84次。作为一台服务器来说，内存并不是无限的，所以总会存在内存耗尽的情况，那么当 Redis 服务器的内存耗尽后，如果继续执行请求命令，Redis 会如何处理呢？_redis中key没有达到过期时间,但是内存满了会怎么样?https://blog.csdn.net/qq_30987095/article/details/143257130?ops_request_misc=%257B%2522request%255Fid%2522%253A%252295fab89f19b3cb10a23ea7030593bb32%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=95fab89f19b3cb10a23ea7030593bb32&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-143257130-null-null.142^v102^control&utm_term=redis%E5%86%85%E5%AD%98%E8%80%97%E5%B0%BD&spm=1018.2226.3001.4187
)
