Redis、RabbitMQ、Kafka：Kubernetes中中间件可靠性实用指南

场景

某电商平台在Kubernetes上运行，使用Redis进行缓存、RabbitMQ处理订单、Kafka进行事件流处理。在一次限时抢购活动中，客户报告结账失败，页面加载缓慢，订单处理延迟。

症状

• 99%响应时间从50ms飙升至2s
• Redis内存使用率超过80%，慢查询日志快速增长
• RabbitMQ队列积压，消息数从数百激增至数十万
• Kafka消费者延迟（lag）从几毫秒增加到分钟级，部分消费者组出现重平衡

诊断

Redis

1. 检查慢查询：redis-cli SLOWLOG GET 10 识别慢命令（如KEYS、SORT、大key操作）。
2. 监控内存：redis-cli INFO memory 查看 used_memory_rss 和 maxmemory，确认是否触发淘汰策略。
3. 检查连接：redis-cli CLIENT LIST 查看连接数是否异常。

RabbitMQ

1. 检查队列状态：rabbitmqctl list_queues name messages_ready messages_unacknowledged 找出积压队列。
2. 查看消费者：rabbitmqctl list_consumers 确认消费者是否正常连接，prefetch设置是否合理。
3. 监控节点：rabbitmqctl status 检查节点健康、alarms（如内存或磁盘告警）。

Kafka

1. 查看消费者组延迟：kafka-consumer-groups --bootstrap-server localhost:9092 --group order-consumer --describe 获取LAG。
2. 检查分区领导者：kafka-topics --describe --topic orders 确认分区分配均匀，领导者分布正常。
3. 监控磁盘和网络：kafka-log-dirs --describe --bootstrap-server localhost:9092 查看磁盘使用。

命令（含安全说明）

Redis

• redis-cli --bigkeys 扫描大key（注意：生产环境避免高峰期运行，使用--sleep选项降低负载）。
• redis-cli config set timeout 30 设置客户端超时（谨慎：修改配置可能导致连接中断，先测试）。

RabbitMQ

• rabbitmqadmin declare queue name=backup queue_args='{"x-max-length":100000}' 创建有限队列防止无限积压。
• 调整prefetch：rabbitmqctl set_consumer_prefetch-size <queue_name> 50（配合消费者重启）。

Kafka

• 增加分区：kafka-topics --bootstrap-server localhost:9092 --alter --topic orders --partitions 6（仅当分区数不超过broker数量，且键设计支持）。
• 重置消费者位移：kafka-consumer-groups --bootstrap-server localhost:9092 --group order-consumer --reset-offsets --to-earliest --execute（危险：会导致重复消费；仅用于测试）。

风险控制

• Redis：开启慢查询日志并设置阈值（slowlog-log-slower-than 10000微秒），配置限制（maxmemory-policy allkeys-lru），使用连接池。
• RabbitMQ：设置队列最大长度（x-max-length）和最大消息字节数（x-max-length-bytes），启用惰性队列，消费者使用手动确认。
• Kafka：配置min.insync.replicas=2，设置消费者max.poll.records和session.timeout.ms，使用监控工具（如Prometheus + JMX Exporter）。

回滚

如果配置修改导致问题，立即回滚： - Redis：redis-cli config set maxmemory-policy volatile-lru 恢复原策略。 - RabbitMQ：删除新创建的有限队列并恢复旧队列。 - Kafka：减少分区（不支持直接减少，需删除主题重建）；重置消费者位移到之前位置。

确保在非高峰期操作，并准备好配置备份。

验证

• 运行合成事务：模拟用户登录、浏览、下单全流程，监控成功率。
• 使用Prometheus+Grafana仪表盘：观察延迟、队列长度、消费者延迟趋势。
• 进行小规模压测：使用locust或jmeter发送模拟流量，检查系统响应。

何时提交OpsGlobal工单

如果团队内部诊断超过30分钟无法定位根因，或需要专家协助进行架构调整、配置优化、故障转移时，请立即提交工单。OpsGlobal SRE团队提供7x24小时支持，帮助您快速恢复服务并优化系统。