如何优化 Redis 消息队列避免大 Key 导致阻塞问题？

处理 Redis 消息队列（包括 List/Stream 模式及发布订阅模式）的大 Key 阻塞，最稳妥的办法是在应用层限制消息体大小，避免直接把大对象塞进 Redis，同时配合异步删除命令清理历史数据。需注意 Redis 发布订阅并非可靠消息队列，持久化队列建议优先使用 List 或 Stream 结构。

先说结论：Redis 单线程模型决定了大 payload 会阻塞主线程，必须在写入前拦截大消息，并用异步方式清理旧数据。

先定位：通过慢日志和内存分析工具找出占用高的大 Key 或长耗时命令。
先做：应用层序列化后检查字节长度，超过阈值（如 100KB）拒绝发送或转存对象存储。
再验证：观察慢日志数量、内存增长趋势及命令延迟，确认阻塞情况缓解。

命令速用版

运维排查时，可用以下命令辅助定位，但避免在生产高峰直接执行高消耗命令：

# 查看慢查询日志
SLOWLOG GET 10

# 查看内存使用情况
INFO memory

# 安全删除大 Key (Redis 4.0+)
UNLINK key_name

# 迭代查找 Key (避免 KEYS *)
SCAN 0 MATCH pattern COUNT 100

# 查看 Key 实际内存占用 (Redis 4.0+)
MEMORY USAGE key_name

为什么会这样

Redis 处理命令是单线程的，这意味着如果一个消息体过大，序列化、内存拷贝和网络传输都会占用主线程时间。一旦往频道或列表塞入几 MB 的数据，会直接卡住主线程，导致所有客户端感知到延迟飙升。此外，PUBLISH 命令本身不校验消息大小，如果订阅者消费慢，消息会在服务端积压（Pub/Sub 无积压，List/Stream 会积压），造成内存异常增长。

代码实战：发送前校验大小

最有效的方式是在调用发送命令前做截断或拒绝。建议在序列化完成后检查字节长度，例如超过 100KB 直接返回错误或不发送。不要只检查原始字符串长度，因为 JSON 序列化后可能膨胀。

// Java 示例：发送前校验
public void sendMessage(Jedis jedis, String channel, Object message) {
    byte[] data = SerializationUtils.serialize(message);
    if (data.length > 100 * 1024) { // 阈值 100KB
        throw new IllegalArgumentException("Message too large");
    }
    jedis.publish(channel, data);
}

# Python 示例
import redis
import json

def send_message(r, channel, message):
    data = json.dumps(message).encode('utf-8')
    if len(data) > 100 * 1024:
        raise ValueError("Message too large")
    r.publish(channel, data)

怎么验证是否生效

执行 INFO commandstats 查看命令耗时变化，观察 slowlog 中是否还有长时间运行的命令。监控 Redis 实例的内存使用率及命令延迟（latency），如果数值归零或显著下降，说明阻塞情况缓解。对于 List/Stream 队列，可监控队列长度（LLEN/XINFO STREAM）确认无异常积压。同时观察业务侧的响应时间是否恢复正常。

常见坑

1. 谨慎处理解码：订阅端可根据业务场景评估是否禁用自动解码，注意字符集兼容性，避免 UTF-8 解析开销过大，但需确保逻辑里对消息长度做预检，丢弃必须发生在反序列化之前。
2. 避免 KEYS *：检索 Key 时使用 SCAN 命令，KEYS * 会导致 Redis 服务阻塞，尤其是有千万级 Key 时。
3. 注意序列化膨胀：中文转 Unicode 等情况可能导致序列化后体积变大，务必在序列化后测字节长度。
4. UNLINK 非绝对无阻塞：UNLINK 虽异步，但对复杂数据结构（如大 Hash）仍有部分同步开销，需视版本和结构而定。
5. Pub/Sub 非可靠队列：Redis 发布订阅并非可靠消息队列，消息丢失不重传，持久化需求请选用 List 或 Stream。

参考建议

建议参考 Redis 官方文档关于 Memory Optimization 及 Pub/Sub 机制说明，结合业务监控告警配置阈值。