RedisRabbitMQKafka可靠性SRE生产故障
场景
假设你管理一个电商平台，依赖 Redis 做缓存、RabbitMQ 处理订单消息、Kafka 收集用户行为日志。某日，订单延迟、页面加载缓慢、日志堆积，影响用户体验。
症状
- Redis: 缓存命中率骤降，响应时间从1ms飙升至100ms，
INFO stats显示evicted_keys激增。 - RabbitMQ: 队列深度超过阈值，
rabbitmqctl list_queues显示messages_ready成千上万，消费者连接数下降。 - Kafka: 消费者延迟增加，
kafka-consumer-groups --describe显示LAG持续增长，磁盘 I/O 高。
诊断
Redis
- 检查内存使用：
redis-cli INFO memory查看used_memory和maxmemory。 - 查看慢查询：
SLOWLOG GET 100分析耗时命令。 - 确认连接数：
CLIENT LIST检查是否超过maxclients。
RabbitMQ
- 队列和连接状态：
rabbitmqctl list_queues name messages_ready messages_unacknowledged。 - 节点健康：
rabbitmqctl status检查running和alarms。 - 内存压力：
rabbitmqctl report查看memory使用。
Kafka
- 消费者滞后：
kafka-consumer-groups --bootstrap-server localhost:9092 --group <group> --describe。 - 分区副本状态：
kafka-topics --describe --topic <topic> --bootstrap-server localhost:9092。 - 磁盘使用：
df -h监控log.dirs分区。
命令
Redis
# 设置最大内存策略（生产环境建议 allkeys-lru）
redis-cli CONFIG SET maxmemory-policy allkeys-lru
# 限制连接数
redis-cli CONFIG SET maxclients 5000
# 查看键空间事件
redis-cli CONFIG SET notify-keyspace-events KEA
RabbitMQ
# 增加队列最大长度（避免内存溢出）
rabbitmqctl set_policy DLQ ".*" '{"max-length":1000000}' --apply-to queues
# 启用惰性队列（减少内存）
rabbitmqctl set_policy LazyQueue ".*" '{"queue-mode":"lazy"}' --apply-to queues
# 查看消费者
rabbitmqctl list_consumers
Kafka
# 调整日志保留时间（释放磁盘）
kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name <topic> --alter --add-config retention.ms=604800000
# 增加分区数（提升并行度）
kafka-topics --alter --topic <topic> --partitions 12 --bootstrap-server localhost:9092
风险控制
- 所有变更前备份配置：
cp /etc/redis/redis.conf /etc/redis/redis.conf.bak。 - RabbitMQ 策略变更影响整个集群，建议先在非生产环境验证。
- Kafka 分区数不可减少，增加前确认下游消费者支持重平衡。
回滚
Redis
redis-cli CONFIG SET maxmemory-policy volatile-lru # 恢复默认
RabbitMQ
rabbitmqctl clear_policy DLQ # 删除策略
Kafka
kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name <topic> --alter --delete-config retention.ms
验证
- Redis: 执行
redis-benchmark -q -n 1000对比延迟；检查INFO stats中evicted_keys下降。 - RabbitMQ: 确认队列深度下降，消费者重连成功：
rabbitmqctl list_queues name messages_ready。 - Kafka: 监控消费者 LAG 归零，磁盘使用率趋于正常。
何时提交工单
- 变更加载后问题未解决。
- 出现 OOM（内存溢出）、磁盘满导致服务不可用。
- 需要迁移数据或重新配置集群（如 Kafka 重新选举 controller）。
- 怀疑硬件或网络层问题。
OpsGlobal 团队提供 24/7 专家支持，可远程诊断并执行复杂恢复操作。
适用场景
适合正在处理 NoSQL、Redis, RabbitMQ, Kafka, 可靠性 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
学习诊断和解决 Redis、RabbitMQ 和 Kafka 常见可靠性问题的实用方法。本指南涵盖真实场景、症状、诊断命令、风险控制、回滚步骤、验证方法及何时提交 OpsGlobal 工单。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。