中间件可靠性：在生产环境中驯服 Redis、RabbitMQ 和 Kafka

场景

一家金融服务客户在高峰时段遇到严重延迟激增和数据不一致问题。其 Kubernetes 平台运行着 Redis 作为缓存和会话存储，RabbitMQ 用于事务消息，Kafka 用于事件流。混合工作负载开始互相影响，导致级联故障。

症状

• Redis：缓存命中率下降，驱逐键数量增加（evicted_keys），延迟超过 100ms。客户端报错 OOM command not allowed when used memory > maxmemory。
• RabbitMQ：队列积压，部分队列消息数达到数百万。消费者连接被断开，并出现 channel error 和 precondition failed。
• Kafka：消费者组滞后（lag）持续增长，分区复制因子低于配置值，ISR（in-sync replicas）缩小。

诊断

1. 收集指标

使用 Prometheus 和 Grafana 观察以下关键指标：

• Redis: redis_memory_used, redis_evicted_keys, redis_commands_processed。
• RabbitMQ: rabbitmq_queue_messages, rabbitmq_connection_open, rabbitmq_channel_open。
• Kafka: kafka_consumergroup_lag, kafka_partition_underreplicated, kafka_server_replica_fetcher_manager_leader_count。

2. 检查日志

# 获取 Redis Pod 日志
kubectl logs -l app=redis -n middleware

# 获取 RabbitMQ 和 Kafka 日志
kubectl logs -l app=rabbitmq -n middleware
kubectl logs -l app=kafka -n middleware

查找异常线索，例如 Redis 的 WARNING 关于内存碎片，RabbitMQ 的 connection_closed_abruptly，Kafka 的 OffsetOutOfRangeException 或 ReplicaFetcherThread 错误。

3. 实时命令

Redis

kubectl exec -it <redis-pod> -- redis-cli INFO memory
kubectl exec -it <redis-pod> -- redis-cli INFO stats | grep evicted
kubectl exec -it <redis-pod> -- redis-cli --bigkeys

检查内存是否接近 maxmemory，以及大键是否存在。

RabbitMQ

kubectl exec -it <rabbitmq-pod> -- rabbitmqctl list_queues name messages consumers
kubectl exec -it <rabbitmq-pod> -- rabbitmqctl list_connections name state

识别哪些队列积压，以及消费者是否仍连接。

Kafka

kubectl exec -it <kafka-pod> -- kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group <group>
kubectl exec -it <kafka-pod> -- kafka-topics --bootstrap-server localhost:9092 --describe --topic <topic>

查看消费者滞后和分区副本状态。

风险控制

• 在操作前对 Redis 进行 SAVE 或 BGSAVE 备份；对 RabbitMQ 进行元数据导出；对 Kafka 确保复制因子大于 1 且 ISR 健康。
• 避免在生产环境直接 FLUSHALL 或删除队列/主题。
• 在更改配置前，确保有回滚方案，并测试连接。
• 使用 kubectl rollout restart 而非手动删除 Pod，以减少干扰。

修复命令（示例）

Redis 调整内存策略

kubectl exec -it <redis-pod> -- redis-cli CONFIG SET maxmemory-policy allkeys-lru
kubectl exec -it <redis-pod> -- redis-cli CONFIG REWRITE

RabbitMQ 临时增加消费者

kubectl scale deployment <consumer-deployment> --replicas=5 -n middleware

Kafka 重置消费者组偏移（需谨慎）

kubectl exec -it <kafka-pod> -- kafka-consumer-groups --bootstrap-server localhost:9092 --group <group> --topic <topic> --reset-offsets --to-earliest --execute

回滚

• 如果调整 Redis 策略导致性能下降，使用 CONFIG SET maxmemory-policy volatile-lru 恢复原设置。
• 如果消费者扩容无效，请缩减副本数。
• 如果 Kafka 偏移重置导致数据乱序，则使用 --to-latest 或原始偏移量回滚。

验证

• 确认 Redis 的 evicted_keys 和 used_memory 恢复正常。
• 检查 RabbitMQ 队列长度是否下降，消费者连接稳定。
• 验证 Kafka 消费者滞后趋近于零，ISR 恢复正常。
• 使用 redis-benchmark 或实际业务请求测试延迟。

何时提交 OpsGlobal 工单

如果您在诊断后仍无法原因，或者需要 24/7 监控和快速响应，请提交 OpsGlobal 工单。我们的 SRE 专家可以提供： - 24/7 全栈监控和告警 - 主动容量规划和性能优化 - 灾难恢复和故障切换演练 - 高级故障排查和根本原因分析

我们在数分钟内介入，帮助您的团队降低 MTTR，保障业务连续性。