保持中间件网格活跃：Redis、RabbitMQ 和 Kafka 可靠性现场指南

场景

一个典型的电子商务平台依赖 Redis 进行缓存、RabbitMQ 处理任务队列、Kafka 处理事件流。某天，应用延迟飙升，订单处理变慢，页面加载超时。基础设施团队发现 Redis 内存使用率接近上限，RabbitMQ 队列深度持续增长，Kafka 消费者落后于最新消息数万条。用户开始抱怨，业务受到影响。

症状

• Redis：INFO memory 显示 used_memory 接近 maxmemory，INFO stats 显示 evicted_keys 和 expired_keys 不断增长，慢查询日志中出现大量 KEYS 或 SMEMBERS 操作。
• RabbitMQ：管理界面或 rabbitmqctl list_queues 显示队列中消息数量急剧增加，消费者数量下降，rabbitmq-diagnostics 报告内存和磁盘告警。
• Kafka：kafka-consumer-groups 显示消费者组 lag 值持续走高，broker 的 CPU 和磁盘 I/O 使用率上升，分区副本出现 ISR 收缩。

诊断

1. 识别热点：确认是否有突发流量或代码缺陷导致中间件压力。使用 APM 和监控工具（如 Prometheus/Grafana）查看请求量、错误率和延迟。
2. Redis 诊断：检查 redis-cli --latency 和 redis-cli --stat，使用 SLOWLOG GET 获取慢命令。分析是否存在大键、热键（hotkeys）问题，以及内存淘汰策略是否合理。
3. RabbitMQ 诊断：检查连接数、通道数、未确认消息数。使用 rabbitmqctl list_consumers 确认消费者是否在线，rabbitmqctl list_queues name messages consumers 查看队列状态。可能的原因包括消费者处理能力不足或死循环。
4. Kafka 诊断：使用 kafka-consumer-groups --describe --group <group> 查看每个分区的 lag。检查 consumer 的 max.poll.records 和 session.timeout.ms 配置，以及 broker 的磁盘和网络指标。

命令

Redis

# 检查内存和键统计
redis-cli INFO memory
redis-cli INFO keyspace

# 查看慢查询
redis-cli SLOWLOG GET 10

# 检查大键（使用第三方工具如 redis-rdb-tools）
redis-cli --bigkeys

# 如果启用集群，查看集群状态
redis-cli CLUSTER INFO

RabbitMQ

# 查看队列状态
rabbitmqctl list_queues name messages consumers

# 查看连接和通道
rabbitmqctl list_connections
rabbitmqctl list_channels

# 检查内存和磁盘警报
rabbitmq-diagnostics check_running
rabbitmq-diagnostics memory_breakdown

# 清空队列（危险操作，需谨慎）
rabbitmqctl purge_queue <queue_name>

Kafka

# 查看消费者组 lag
kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group my-consumer-group

# 查看 topic 的详细信息
kafka-topics --bootstrap-server localhost:9092 --describe --topic orders

# 查看 broker 日志中的异常
journalctl -u kafka -n 200

风险控制

• Redis：设置合理的 maxmemory-policy（建议 allkeys-lru 或 volatile-lru），避免使用 KEYS 命令，改用 SCAN。启用持久化（RDB/AOF）时确保内存有冗余。
• RabbitMQ：配置队列长度限制（x-max-length）和消息 TTL，使用死信队列处理无法消费的消息。为大流量队列启用惰性队列（lazy queue）以减少内存压力。
• Kafka：调整 replica.lag.time.max.ms 和 min.insync.replicas 以避免 ISR 收缩。优化 consumer 端 fetch.max.bytes 和 max.poll.records，防止处理超时。
• 通用：为每个中间件设置监控告警，如 Redis 内存使用率、RabbitMQ 队列深度、Kafka 消费者 lag。在变更前进行压测并备份配置。

回滚

如果调整配置后问题恶化，应立即回滚。

• Redis：使用 CONFIG GET 和 CONFIG SET 临时修改参数，但持久化到配置文件需手动更新。如果启用了 AOF，回滚配置不需要重启。若误用 FLUSHALL，立即停止 Redis 并恢复最后一次备份（RDB）。
• RabbitMQ：如果添加了策略导致异常，删除策略：rabbitmqctl clear_policy <name>。如果队列被 purge，无法恢复，需从生产者或备份重建。
• Kafka：如果修改了 broker 配置，重启 Kafka 实例（注意滚动重启）。对于 consumer group，重置 offset 可以从 --to-earliest 或 --to-latest 恢复，但注意会重复或丢失消息。
• 安全提示：任何破坏性命令前确保有备份，并通知团队成员。

验证

执行修复后，需要验证中间件是否恢复健康。

• Redis：redis-cli INFO stats 中 evicted_keys 趋于稳定，延迟恢复正常。通过 redis-cli --latency 确认延迟 <1ms。
• RabbitMQ：队列深度下降，消费者数量恢复，rabbitmq-diagnostics status 显示所有节点运行。
• Kafka：消费者组 lag 降为 0 或接近 0，ISR 稳定。通过 kafka-producer-perf-test 和 kafka-consumer-perf-test 验证吞吐量。
• 业务层面：核心 API 响应时间下降，订单处理不再积压。

何时提交 OpsGlobal 工单

如果你的团队面临以下情况，是时候寻求 OpsGlobal 的帮助：

• 中间件频繁出现同样的问题，但根因不明确。
• 需要深度调优或架构级改造（如分片、集群迁移）。
• 生产环境出现数据丢失或不一致，需要快速恢复。
• 团队缺乏 7x24 小时支持，而问题发生在关键时段。

OpsGlobal 的 SRE 专家可以快速定位瓶颈，提供生产级别的加固方案，并根据 SLA 及时响应。不要等到故障蔓延，提前提交工单以确保业务连续性。