omem是redis客户端输出缓冲区当前占用的内存字节数，反映未发出的响应数据量；超10mb需警惕，超50mb likely失控，可通过client list排序定位，结合client info分析原因，必要时client kill止损。
CLIENT LIST 能看到每个客户端的 omem，但得先理解它代表什么
omem 是 Redis 客户端输出缓冲区（output buffer）当前占用的内存字节数，不是客户端本身内存，而是 Redis 为该连接暂存、还没发出去的响应数据。比如一个 LRANGE biglist 0 -1 返回几 MB 数据，如果客户端处理慢或网络卡住，这部分数据就堆在 omem 里，持续不释放就会吃光 Redis 内存。
常见错误现象：used_memory 暴涨但 key 数量稳定；connected_clients 不高，blocked_clients 也正常；用 redis-cli --bigkeys 扫不出大 key——这时候大概率是某个客户端的 omem 在悄悄膨胀。
-
CLIENT LIST输出中每行的omem=值就是关键指标，单位是字节 - 生产环境慎用
CLIENT LIST | grep "omem=" | sort -k...这类管道命令，容易因输出量大阻塞主线程；建议先用CLIENT LIST重定向到文件再分析 - 单个客户端
omem > 10MB就值得警惕；超过 50MB 很可能已失控
如何快速定位 omem 异常高的客户端
直接执行 redis-cli CLIENT LIST，然后过滤并按 omem 排序：
redis-cli CLIENT LIST | awk -F'[ =]' '{print $2, $12}' | sort -k2 -nr | head -10
输出类似：id=12345 omem=8924567，说明客户端 ID 12345 的输出缓冲区占了约 8.5MB。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 注意字段顺序：不同 Redis 版本
CLIENT LIST字段位置可能微调，Redis 6 默认字段顺序中omem是第 12 个字段（以空格和等号分隔），保险起见可先跑一次redis-cli CLIENT LIST | head -1确认位置 - 如果看到大量客户端
omem都在几百 KB 以上，且qbuf（输入缓冲区）也偏高，可能是客户端消费能力不足或存在订阅未及时READ的 PUB/SUB 连接 - 对疑似客户端，可用
CLIENT INFO id=12345查看更详细上下文，包括addr（来源 IP）、cmd（最后执行命令）、age（连接时长）
omem 居高不下的真实原因和对应动作
不是所有高 omem 都是 bug，得结合场景判断：
- 主从同步：从节点连接的
omem高属正常，尤其在全量同步后增量积压阶段；关注slave类型连接的omem是否随repl_backlog_size增长而缓慢下降 - PUB/SUB 客户端：若订阅了高吞吐 channel 却没及时
READ，omem会持续累积；检查客户端是否调用了redisClient.subscribe()后忘了redisClient.on("message", ...)处理逻辑 - 普通命令响应过大：如 Java 应用用 Jedis 执行
HGETALL hugehash，返回结果超百 MB，而客户端线程卡在反序列化或 GC，导致 Redis 缓冲区堆积 - 连接泄漏：客户端获取连接后没归还连接池，连接长期 idle 但缓冲区残留未清空数据；此时
idle值会很大，omem却不降
确认问题后，最直接动作是用 CLIENT KILL ID 12345 主动断开异常连接——Redis 会立即释放其 omem，这是止损最快的方式。
配置 client-output-buffer-limit 是预防手段，但别乱设
Redis 允许为三类连接设置输出缓冲区硬限制：normal（普通客户端）、slave（从节点）、pubsub（订阅者）。配置项是 client-output-buffer-limit，格式如：normal 0 0 0 表示不限制。
- 生产环境不建议设成
0 0 0，应至少设软限，例如normal 268435456 67108864 60：表示普通客户端缓冲区达 256MB 或连续 60 秒超 64MB 就自动断连 - 设太小会导致误杀——比如批量导出场景下合法的大响应被截断；设太大又失去保护意义
- 修改后需用
CONFIG REWRITE持久化，否则重启失效；临时调整可用CONFIG SET client-output-buffer-limit "normal 256mb 64mb 60"
真正难的是区分“合理的大响应”和“失控的缓冲区膨胀”，这没法靠阈值全自动解决，必须结合 CLIENT LIST + 业务日志 + 客户端监控才能闭环。
