确保中间件可靠性：面向 SRE 的 Redis、RabbitMQ 和 Kafka 最佳实践指南

在生产环境中，Redis、RabbitMQ 和 Kafka 是支撑微服务架构的关键中间件。任何可靠性问题都可能导致级联故障。本文提供一套系统性方法，用于诊断并解决这些中间件的常见问题。

场景

假设你的 Kubernetes 集群运行着多个微服务，其中： - Redis 用作缓存和会话存储 - RabbitMQ 处理异步任务队列 - Kafka 用于事件流处理

某天，用户报告延迟增加，部分请求超时，甚至出现数据不一致。

症状

• Redis：内存使用率接近上限，慢查询日志增长，主从同步延迟加大
• RabbitMQ：队列堆积，消费者连接频繁断开，磁盘报警
• Kafka：消费者组滞后增加，broker 磁盘 I/O 饱和，分区领导者重新选举

诊断

Redis

• 使用 redis-cli info memory 检查内存碎片率和最大内存
• 执行 redis-cli slowlog get 50 获取慢查询详情
• 在 Kubernetes 中：kubectl exec pod/redis-pod -- redis-cli -a $PASSWORD info（注意密码安全）
• 观察 kubectl top pod 的 CPU/内存使用

RabbitMQ

• 运行 rabbitmqctl list_queues name messages_ready messages_unacknowledged 检查队列堆积
• 使用 rabbitmqctl list_connections 查看连接状态
• 在 Kubernetes：kubectl logs deployment/rabbitmq -c rabbitmq | grep -i error

Kafka

• 检查消费者组延迟：kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe
• 监控 broker 磁盘：kafka-log-dirs --bootstrap-server localhost:9092 --describe
• Kubernetes：kubectl exec pod/kafka-pod -- df -h /var/lib/kafka/data

风险控制

• 为 Redis 配置最大内存和淘汰策略（如 allkeys-lru），启用 RDB/AOF 持久化
• RabbitMQ：设置队列最大长度、消息 TTL，使用 HA 镜像队列
• Kafka：调整 replication.factor 和 min.insync.replicas，确保充足磁盘空间
• Kubernetes：设置资源请求/限制，配置 liveness 和 readiness 探针

回滚

• Redis：从 AOF 或 RDB 备份恢复，或回滚到上一个部署版本
• RabbitMQ：如果新增了交换器或队列，删除它们，恢复旧配置；从备份恢复数据
• Kafka：使用 kafka-reassign-partitions 重新分配分区，或降级消费者组偏移

验证

• Redis：执行 redis-cli ping 确认连通，用 redis-benchmark 测试延迟
• RabbitMQ：发送测试消息并确认消费，检查监控面板队列长度归零
• Kafka：生产并消费一条消息，确认延迟和吞吐量恢复

何时提交 OpsGlobal 工单

• 你尝试了上述诊断和操作后问题依然存在
• 需要专业数据恢复（如损坏的 RDB 文件）
• 涉及复杂的集群调优或架构设计问题
• 需要 7×24 小时在线支持

OpsGlobal 的 SRE 团队能提供深度分析和快速修复，确保你的中间件集群稳定运行。