Redis、RabbitMQ、Kafka中间件可靠性深度实战指南

场景

某电商平台大促期间，订单处理系统突然变慢，用户反馈超时。监控告警显示Redis内存飙升、RabbitMQ队列深度陡增、Kafka消费者组滞后持续增长。

症状

• Redis: 客户端连接超时，INFO stats 显示evicted_keys激增，内存使用率接近上限。
• RabbitMQ: 队列消息积压，rabbitmqctl list_queues 显示unacknowledged消息数异常高，磁盘写入I/O等待时间上升。
• Kafka: 消费者组 kafka-consumer-groups --bootstrap-server localhost:9092 --group order-group --describe 显示LAG列数值持续增长，且消费者线程报错Rebalance in progress。

诊断

1. Redis：使用 redis-cli info memory 检查内存碎片率（mem_fragmentation_ratio）和键过期策略。使用 redis-cli --bigkeys 查找大键。若发现大量临时缓存未设置TTL，则原因可能是内存泄漏。
2. RabbitMQ：rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers memory 定位阻塞队列。rabbitmqctl eval 'rabbit_disk_monitor:get_disk_free_list().' 检查磁盘空间。若消息持久化超量，可能是消费者处理速度不足。
3. Kafka：kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec 查看输入速率。kafka-consumer-groups --describe --group order-group --members --verbose 检查分区分配是否均衡。若分区重复均衡导致消费停顿，则可能是消费者心跳超时。

常用命令

# Redis
redis-cli info stats | grep evicted_keys
redis-cli -h <host> -p <port> --bigkeys

# RabbitMQ
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers memory --no-table-headers
rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

# Kafka
kafka-consumer-groups --bootstrap-server localhost:9092 --group order-group --describe
kafka-topics --bootstrap-server localhost:9092 --describe --topic orders

风险控制

• Redis：启用maxmemory-policy allkeys-lru（非阻塞），设置合理的超时时间。避免大键（>1MB）。使用Sentinel或Cluster实现高可用。
• RabbitMQ：配置镜像队列以确保高可用。限制队列最大长度（x-max-length或x-max-length-bytes）。设置消费者预取计数（prefetch count）为1，防止少数消费者过载。
• Kafka：调整rebalance超时（session.timeout.ms）和心跳间隔。使用粘性分区分配(sticky partitioner)减少重平衡。监控消费者lag并设置自动告警。

回滚

• Redis：若因AOF重写导致性能下降，先关闭重写（CONFIG SET auto-aof-rewrite-percentage 0），待负载降低后手动重写。如果内存不足，临时扩容或使用swap（不建议生产）。
• RabbitMQ：暂停生产者（如通过断路器），允许消费者清空积压。如果节点磁盘满，将队列迁移到健康节点（rabbitmqctl set_cluster_name ha）。
• Kafka：增加消费者实例数或调整fetch.min.bytes减少请求次数。如果副本不同步，临时将min.insync.replicas设为1（风险高，需谨慎）。

验证

• Redis：执行 redis-cli ping 返回PONG，redis-cli info commandstats 显示命令延迟恢复正常。
• RabbitMQ：rabbitmqctl status 显示running，rabbitmqctl list_queues 队列深度下降至正常水平。
• Kafka：kafka-consumer-groups --describe LAG为0或小范围波动，消费者进程日志无错误。

何时提交OpsGlobal工单

当内部团队已执行上述诊断但仍无法恢复时： - 持续出现硬件级故障（如磁盘损坏、网络分区）。 - 需要高难度数据恢复（如损坏的RDB文件修复）。 - 大规模集群性能调优（如Kafka分区数过多导致控制器瓶颈）。 - 缺乏特定中间件专家（如RabbitMQ集群脑裂处理）。

OpsGlobal SRE团队可提供7x24小时远程支援，包括实时故障排查、架构优化和灾备方案。