系统维护常见场景

接口突然延时

接口从 200ms 飙升至 2s，但是 cpu 正常，怎么排查

• 第一，立即用 Arthas 的 trace 命会追踪方法调用链，定位耗时环节
• 第二，检查数据库监控，看是不是 SOL 执行变慢或连接池满了
• 第三，排查 Redis 等中间件，看看网络连接和响应时间
• 第四，分析 GC 日志，说不定是有 FulGC 但 CPU 沒体现出来
• 第五，最后查网络状况，比如 DNS 解析或带宽占用

Redis 高并发阻塞

Redis 阻塞命令是指执行时会占用 Redis 主线程，导致其他命令无法并发执行的命令。Redis 采用单线程模型处理客户端请求，当执行阻塞命令时，整个 Redis 实例会暂停响应其他请求。

• redis 的阻塞命令
  • 高复杂度的命令：keys、FLUSHALL、SORT
    • 解决办法：使用 scan 替代
  • 大数据量操作：SMEMBERS、LRANGE、HGETALL
    • 解决办法：使用分页查询、限制返回数量和避免全量获取大集合数据
  • 阻塞等待命令：BLPOP、BRPOP
    • 解决办法：合理设置超时时间、监控阻塞客户端数量、避免无限期的阻塞
  • 持久化命令：SAVE、BGSAVE 同步保存和后台保存都有可能造成阻塞；FLUSHALL/FLUSHDB 清空数据，建议使用 ASYNC 选项
    • 解决办法：在业务低峰期执行持久化阻塞操作
• 阻塞造成的危害
  • 请求堆积，响应时间急剧增加
  • 连接超时，客户端连接超时，导致业务异常
  • 雪崩效应，缓存不可用导致请求直接打到数据库
  • 系统崩溃，极端情况下可能导致整个系统不可以使用
• 监控和预防
  • 慢查询日志：监控执行时间超过阈值的命令
  • 客户端连接数：监控阻塞的客户端数量
  • QPS 和响应时间：监控整体性能指标
  • 代码审查：禁止在生产环境中执行危险命令
  • 命令重命名：通过配置禁用危险命令
  • 分片策略：将大集合分拆为多个小集合
• 架构优化：使用 redis cluster 分片和读写分离