Redis、RabbitMQ 和 Kafka 在 Kubernetes 中的可靠性：实战指南

场景

你的应用依赖 Redis 进行缓存、RabbitMQ 处理任务队列、Kafka 进行事件流。突然，平台团队报告了一系列警报：Redis 内存使用飙升，RabbitMQ 队列堆积，Kafka 消费者延迟增加。用户抱怨结账缓慢和通知丢失。你需要快速采取行动而不让情况变得更糟。

症状

• Redis：延迟尖峰、OOM 终止、驱逐风暴、故障转移期间的 READONLY 错误。
• RabbitMQ：队列深度增长、消费者连接断开、代理节点 CPU 高、日志中出现 channel.error。
• Kafka：消费者组延迟、ISR 收缩、NotLeaderForPartition 异常、分区副本不足。

诊断

从 Kubernetes 级别的检查开始：资源使用、Pod 健康和网络。然后深入每个中间件。

1. Kubernetes 级别： - kubectl get pods -n <namespace> - 查看重启或 CrashLoopBackOff。 - kubectl top pods -n <namespace> - 检查 CPU/内存。 - kubectl describe pod <pod> - 检查事件、探针、限制。

2. Redis 诊断： - redis-cli info memory - 检查 used_memory、maxmemory、evicted_keys。 - redis-cli info stats - 查看拒绝连接和错误。 - redis-cli latency doctor - 识别延迟来源。 - redis-cli --bigkeys - 查找导致分区的大键。

3. RabbitMQ 诊断： - rabbitmqctl list_queues name messages consumers - 观察队列深度。 - rabbitmqctl list_channels - 检查通道状态。 - rabbitmq-diagnostics -q ping - 检查代理心跳。 - rabbitmq-diagnostics runtime - 检查内存、文件描述符和进程详情。

4. Kafka 诊断： - kafka-consumer-groups.sh --bootstrap-server <broker> --describe --group <group> - 检查延迟。 - kafka-topics.sh --describe --topic <topic> - 查看分区领导和 ISR。 - kafka-broker-api-versions.sh --bootstrap-server <broker> - 确认连通性。 - 在 Kafka Pod 内检查日志中的错误，如 "NotLeaderForPartition"。

命令

Redis

# 检查内存和键空间命中率
redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

# 监控驱逐和 OOM 终止
redis-cli info stats | grep -E "evicted_keys|rejected_connections"

# 慢查询日志
redis-cli slowlog get 10

# RDB 保存状态
redis-cli info persistence | grep rdb_last_save

RabbitMQ

# 列出队列的消息数和消费者数
rabbitmqctl list_queues name messages consumers

# 检查连接和通道数量
rabbitmqctl list_connections state recv_oct discards

# 获取内存和警报状态
rabbitmqctl status | grep -A 10 "Memory"

# 启用/禁用管理 API？不需要。

Kafka

# 列出主题的分区和副本
kafka-topics.sh --describe --bootstrap-server localhost:9092

# 检查消费者组延迟
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

# 如有需要（仅紧急情况）修改消息保留时间
kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name my-topic --add-config retention.ms=3600000

风险控制

• 为所有中间件 Pod 设置 CPU/内存的资源请求和限制。过度配置会导致吵闹的邻居；配置不足会导致 OOM 终止。
• 正确配置 Kubernetes 的存活探针和就绪探针。对于 Redis，使用 redis-cli ping；对于 RabbitMQ，使用健康检查端点或 rabbitmq-diagnostics ping；对于 Kafka，使用 kafka-broker-api-versions.sh 或内置的 JMX exporter。
• 使用 PodDisruptionBudgets 防止在节点维护期间所有代理被驱逐。
• 启用持久化：Redis AOF（使用 appendfsync everysec）、RabbitMQ 队列的持久标志、Kafka 的 log.dirs 在持久卷上。
• 利用 Redis Cluster、RabbitMQ 仲裁队列和 Kafka 机架感知实现高可用。
• 设置关键指标的警报和仪表板：内存使用、连接数、消息延迟、CPU 利用率。

回滚

• Redis：如果最近的 CONFIG SET 导致不稳定，使用 redis-cli CONFIG REWRITE 恢复之前的配置。对于 Kubernetes，回滚 ConfigMap 并执行滚动重启。
• RabbitMQ：如果插件更改或策略更新导致问题，禁用插件或回滚策略。使用 rabbitmqctl set_policy 设置旧值。对于版本问题，切换回之前的镜像版本并执行滚动更新。
• Kafka：如果主题配置更改（如保留时间或分区数）适得其反，使用 kafka-configs.sh 恢复主题覆盖。如果问题来自代理版本升级，在保持相同存储的同时回滚镜像版本。

始终先在暂存环境中测试回滚。不要在不停用客户端流量的情况下回滚有状态集群。

验证

• Redis：检查 redis-cli info stats 中的 evicted_keys 是否下降，命中率是否稳定。从客户端运行 redis-cli ping。
• RabbitMQ：确认队列深度正在下降，消费者连接稳定。再次使用 rabbitmqctl list_queues。
• Kafka：确认消费者延迟降至正常范围，kafka-topics.sh --describe 显示所有 ISR 同步。

同时监控应用层面的错误率和延迟百分位数，确保用户体验恢复。

何时提交 OpsGlobal 工单

在以下情况下提交工单： - 根本原因不清楚，或多次干预后相同故障重复发生。 - 需要恢复损坏的 Redis RDB/AOF 文件，或手动进行 Kafka 分区重新分配。 - 中间件版本超过生命周期，需要升级策略。 - 需要帮助设计全面的多区域部署，或调优底层内核参数。