小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
场景01
类型
graph LR
流量增大 --> 服务处理过慢--> 线程阻塞--> 多余请求进入队列--> oldGC频繁--> OOM导致情况进一步加剧
处理思路
建议优先扩容 解决问题
- 线上sudo权限申请
- 线上数据dump
- Tomcat重启
- 服务扩容
- SLB流量摘除
预防流程
- 未受限线程清理
- 核心业务监控
- 服务容错 （超时&重试 熔断 降级、 限流、隔离）
- 弹性容器部署
场景02
mysql为增加select速度，会把被访问的磁盘页加载到内存的LRU中 这部分内存为buffer pool。
随着数据量的逐步增大，原先有问题的SQL查出来的数据逐步增多，放到MySQL的buffer pool时正好到了MySQL缓存容量的临界点，缓存命中率降低，MySQL需要从硬盘读取数据，io 升高，CPU被耗光。
类型
graph LR
MySQL缓存命中率降低 --> i/o升高--> cpu耗光
处理思路
- 新增或修改db的查询语句后，实时关注机器的load与io,和慢查询记录，尽早发现系统异常
- 关注db buffer pool的命中率
场景03
服务无限重试，log日志将网卡打满
类型
graph LR
服务容量过载 --> 客户端不合理重试--> 故障放大N倍--> 累积出雪崩
处理思路
建议考虑过载保护和限流
- 客户端对外部依赖支持过载保护，参考HYstrix的做法。
- ngx接入层支持过载保护机制，后端服务可用性降低时，ngx支持自动限流或熔断，避免后端容量过载，故障扩大
- 服务端支持限流 避免出现容量过载
