中间件可靠性实战：Redis、RabbitMQ、Kafka 生产级故障排查指南

场景

某电商平台大促期间，订单服务依赖 Redis 缓存、RabbitMQ 消息队列和 Kafka 事件总线。突然，订单延迟飙升，部分请求超时，监控告警爆发。

症状

• Redis: redis-cli --latency 显示延迟超过 100ms（正常 <1ms）；INFO 命令中 used_memory_peak 接近 maxmemory。
• RabbitMQ: 管理 UI 显示队列堆积，rabbitmqctl list_queues messages_ready 大量消息未消费；节点内存告警。
• Kafka: kafka-consumer-groups --describe 显示消费者滞后数万条；kafka-run-class.sh kafka.tools.JmxTool 报告请求处理时间升高。

诊断

Redis

# 检查慢查询
redis-cli SLOWLOG GET 10
# 检查内存使用
redis-cli INFO memory | grep used_memory_human
# 检查大 key
redis-cli --bigkeys
# 检查连接数
redis-cli CLIENT LIST | wc -l

RabbitMQ

# 查看队列详情
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
# 查看节点内存
rabbitmqctl status | grep memory
# 查看连接
rabbitmqctl list_connections state user
# 未确认消息
rabbitmqctl list_channels connection messages_unacknowledged

Kafka

# 消费者组滞后
kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe
# 检查分区 leader 分布
kafka-topics --describe --topic my-topic --bootstrap-server localhost:9092
# 查看日志段大小
kafka-log-dirs --bootstrap-server localhost:9092 --describe --topic-list my-topic
# 请求处理时间（需开启 JMX）

风险控制

执行任何变更前： - 对于 Redis：如果内存接近上限，先设置 maxmemory 并调整淘汰策略 allkeys-lru。注意：FLUSHALL 是危险操作，禁止在生产环境直接执行。 - 对于 RabbitMQ：需确认消费者健康，必要时扩容消费者实例。强制删除队列会丢失数据。 - 对于 Kafka：调整配置前备份 server.properties，不要在生产环境使用 kafka-delete-records 除非已备份。

回滚

Redis

如果修改了配置：CONFIG SET maxmemory 0（恢复默认）；如果执行了 FLUSHALL，需从 RDB/AOF 恢复，但可能丢失增量数据。

RabbitMQ

如果添加了策略（如 TTL）：rabbitmqctl clear_policy <queue>；如果修改了参数：rabbitmqctl set_parameter 恢复原值。

Kafka

如果调整了 log.retention.hours：改回原值并重启 broker（注意滚动重启）。

验证

• Redis: 执行 redis-cli --latency 确认延迟恢复，观察 INFO 中内存使用下降。
• RabbitMQ: 检查队列深度下降，rabbitmqctl list_queues messages_ready 减少。
• Kafka: 消费者滞后归零，kafka-consumer-groups --describe 显示 LAG 为 0。

何时提交 OpsGlobal 工单

• 需要跨团队协调的变更（如数据库存储扩容）。
• 根本原因不明确，需要深度分析。
• 回滚后问题依旧，或需要重建集群。
• 涉及安全补丁或架构重构。

总结

通过系统化的症状识别、诊断命令和安全操作，多数中间件问题可在 10 分钟内恢复。OPSGLOBAL 提供 7x24 专家支持，确保您的关键链路永不停机。