中间件可靠性实战：Redis、RabbitMQ与Kafka的故障排查与恢复

场景

某电商平台在Kubernetes上运行Redis、RabbitMQ和Kafka。大促期间，Redis缓存频繁超时、RabbitMQ消息堆积、Kafka消费者组偏移重置，导致订单延迟。

症状

• Redis: 应用日志出现“Connection refused”或“Timeout”错误，缓存命中率骤降。
• RabbitMQ: 队列深度暴涨，消费者吞吐下降，部分消息被requeue或丢失。
• Kafka: 消费者组出现“OffsetOutOfRange”或“Rebalance”频繁触发，lag升高。

诊断

Redis

1. 检查Redis服务状态： bash kubectl exec -it redis-pod -- redis-cli ping 返回PONG表示正常。若连接失败，查看Pod日志： bash kubectl logs redis-pod --tail=50
2. 检查Sentinel或Cluster状态： bash redis-cli -h redis-sentinel -p 26379 sentinel master mymaster
3. 检查内存和慢查询： bash redis-cli info memory redis-cli slowlog get

RabbitMQ

1. 查看节点状态： bash kubectl exec rabbitmq-pod -- rabbitmqctl status
2. 检查队列和消费者： bash rabbitmqctl list_queues name messages_ready messages_unacknowledged rabbitmqctl list_consumers
3. 查看日志： bash kubectl logs rabbitmq-pod

Kafka

1. 检查Broker和Topic元数据： bash kubectl exec kafka-pod -- kafka-broker-api-versions.sh --bootstrap-server localhost:9092 kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092
2. 查看消费者组状态： bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group order-group --describe
3. 检查日志段： bash kafka-run-class.sh kafka.tools.DumpLogSegments --files /data/kafka/orders-0/00000000000000000000.log --print-data-log

风险控制

• Redis: 使用哨兵或者集群模式避免单点；设置maxmemory和eviction策略（如allkeys-lru）；开启RDB/AOF持久化。
• RabbitMQ: 配置镜像队列（ha-mode: all）；启用发布者确认（publisher confirms）和消费者手动ack；设置死信交换机处理失败消息。
• Kafka: 设置副本因子（replication.factor >= 3）；最小同步副本（min.insync.replicas=2）；生产者设置acks=all；消费者启用自动偏移重置策略none或earliest。

回滚

• Redis: 恢复RDB快照或AOF文件，重新加载到主节点。
• RabbitMQ: 如果部署了镜像队列，切换故障节点；或者从备份恢复队列数据。
• Kafka: 使用kafka-reassign-partitions工具重新分配副本；如果数据损坏，从备份恢复topic数据。

验证

• Redis: redis-cli --latency -h <host>测试延迟；redis-cli info persistence检查持久化状态；模拟故障切换后验证自动恢复。
• RabbitMQ: 发送测试消息并消费确认，检查队列深度和ack速率。
• Kafka: 生产/消费测试消息，检查偏移量无跳变；使用kafka-verifiable-producer和kafka-verifiable-consumer验证端到端。

何时提交OpsGlobal工单

• 当故障超出团队处理能力（如跨AZ网络分裂、数据严重损坏）；
• 需要权威的架构审查（如集群扩缩容方案）；
• 持续出现不稳定现象且无法定位根因；
• 希望建立更完善的监控与告警体系。