中间件可靠性实战：Redis、RabbitMQ 与 Kafka

场景描述

在现代微服务架构中，Redis、RabbitMQ 和 Kafka 是三大核心中间件。某日，业务团队报告系统出现间歇性故障：用户请求变慢，某些订单处理延迟，甚至偶尔丢失消息。初步排查发现，Redis 缓存命中率下降，RabbitMQ 队列出现大量积压，Kafka 消费者组出现明显延迟。

症状识别

• Redis：INFO stats 显示 evicted_keys 持续增长，keyspace_hits 和 keyspace_misses 比例失调，SLOWLOG 中出现大量慢查询。
• RabbitMQ：队列中 messages 和 messages_unacknowledged 数量持续上升，消费者连接数下降，内存或磁盘告警触发。
• Kafka：消费者组描述中 LAG 持续增加，分区 ISR（In-Sync Replicas）收缩，或出现 OutOfRangeException 错误。

诊断命令

Redis 诊断

# 查看关键统计信息
redis-cli INFO stats
redis-cli INFO keyspace

# 查看慢查询日志（最近 10 条）
redis-cli SLOWLOG GET 10

# 检查持久化状态，避免 RDB/AOF 重写期间阻塞
redis-cli INFO persistence

注意：这些命令都是只读的，不会影响业务。但 SLOWLOG RESET 会清除日志，请在需要保留日志时避免使用。

RabbitMQ 诊断

# 列出所有队列的详情（消息数量、未确认数、消费者数）
rabbitmqctl list_queues name messages messages_unacknowledged consumers

# 查看连接状态和通道
rabbitmqctl list_connections name state

# 检查是否有内存或磁盘告警
rabbitmqctl list_nodes name mem_used disk_free_alarm

这些命令不会修改任何状态，但需要管理权限。建议在维护窗口内执行。

Kafka 诊断

# 查看所有消费组的当前消费进度与延迟
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 --describe --all-groups

# 查看主题的分区副本和 ISR 状态
kafka-topics.sh --bootstrap-server <broker>:9092 --describe --topic <topic>

# 查看经纪人的日志和磁盘使用（通过 JMX 或日志）
# 示例：获取未同步分区数
kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

kafka-run-class.sh 会启动 JVM，可能短暂增加内存开销，请评估后再执行。所有命令都只读。

风险控制

在实施修复前，必须控制风险：

1. 备份配置：将 Redis 的 redis.conf、RabbitMQ 的 rabbitmq.conf、Kafka 的 server.properties 及消费者组配置全部备份。
2. 启用维护模式：对于 Kafka，如果可能，暂停生产端发送；对于 RabbitMQ，暂时关闭部分消费者（但需谨慎，避免堆积更多消息）。
3. 限流与熔断：在入口处增加限流，断路器打开，防止雪崩。
4. 设置变更窗口：所有操作必须在低峰期进行，并通知相关团队。
5. 监控增强：开启详细日志和指标收集，确保任何异常能立即被发现。

回滚方案

Redis 回滚

• 如果修改了配置（如 maxmemory-policy），可以通过还原备份并重启 Redis 服务回滚。
• 安全回滚步骤： bash # 复制原配置 cp /etc/redis/redis.conf.bak /etc/redis/redis.conf # 重启 Redis（注意：会中断服务，请谨慎操作） sudo systemctl restart redis
• 不要使用 FLUSHALL 或 FLUSHDB 进行回滚，否则会丢失数据。

RabbitMQ 回滚

• 如果使用策略或参数调整，可以删除或还原策略： bash rabbitmqctl clear_policy <vhost> <policy_name> # 或重新应用备份的策略定义
• 关闭高可用队列的自动同步可能会引发镜像队列不一致，务必先确认蓝图。

Kafka 回滚

• 如果修改了消费者 group 的 offset，可以通过重置 offset 来回滚： bash kafka-consumer-groups.sh --bootstrap-server <broker>:9092 --group <group> --topic <topic> --reset-offsets --to-earliest --execute

  这会重新消费历史消息，可能导致重复处理，需谨慎。

• 如果是版本升级导致的问题，可以回滚到之前的二进制版本，并恢复原配置文件。

验证步骤

修复后，必须验证：

• Redis：检查 evicted_keys 是否回落，命中率是否恢复，SLOWLOG 变短，INFO ping 的延迟恢复正常。
• RabbitMQ：队列中的 messages 和 unacknowledged 持续下降，消费者数量稳定，内存/磁盘告警解除。
• Kafka：消费者组的 LAG 逐步归零，ISR 恢复完整，分区副本均同步。

同时，进行业务层面的验证：模拟支付、订单等关键流程，确认没有消息丢失或重复。关注 SLO 指标（如 p99 延迟）是否恢复到基线。

何时提交 OpsGlobal 工单

如果遇到以下情况，建议立即提交工单：

1. 经过 30 分钟以上排查仍无法定位根因。
2. 出现数据丢失或损坏，需要专业的数据修复服务。
3. 疑似底层硬件或内核问题，如磁盘 I/O 异常、网络抖动。
4. 需要跨可用区或跨集群的复杂故障转移。
5. 团队缺乏相关中间件的深度运维经验，需要专家指导。

OpsGlobal 的 SRE 团队可以在不侵入业务代码的情况下，提供快速诊断、性能调优和灾难恢复支持，帮助您将停机时间降到最低。