Appearance
数据与基础设施排障专题
这里不是新的原理专题,而是故障入口页。适合先按症状定位,再回到 MySQL、Redis、MQ、检索和服务器等专题做系统补强。
起步入口4 组
专题序列5 个
关联文章21 篇
起步入口先选入口
起步入口先查数据库连接与资源耗尽适合业务大量报连接异常、连接池被打满或数据库资源明显吃紧时先进入。
起步入口先查 Nginx 和上游服务链路适合站点出现 502、上游不可用、请求无法穿透到应用时优先进入。
起步入口先查缓存、消息和检索链路适合接口抖动已经扩散到 Redis、MQ、ES、ClickHouse 这类中间件时优先进入。
起步入口先查机器空间和基础资源适合已经报警、日志写不进去、文件落盘失败,或者 Kubernetes / 节点资源异常时先进入。
阅读路径按场景进入
入门打底先建立基础设施故障的排查顺序适合先把数据库连接、网关异常、缓存热点、消息积压和磁盘空间这几类高频故障的基本排查路径补顺。
核心原理把资源状态、配置问题和链路瓶颈联系起来适合理解为什么一个表面的连接报错、热点抖动或查询超时,背后可能是容量、配置、依赖链路或资源耗尽问题。
工程实战围绕真实链路回到专题做补强适合先从线上现象切入,随后回到存储、中间件、服务器和网关专题把长期治理动作补齐的人。
专题序列数据与基础设施排障专题本专题共 5 个序列 / 21 篇文章扩容后的文章会继续按序列归档在这里,适合先选一条主线再往下读。
4 篇文章数据库与网关故障排查适合把数据库连接、死锁、网关异常和磁盘空间问题放在一条排障线上看。起步文章:MySQL 连接数打满时怎么排查
- MySQL 连接数打满时怎么排查
- 数据库死锁和锁等待超时案例怎么复盘
- Nginx 502 怎么排查
- Redis 热 Key 突增时怎么止血和回查
- RabbitMQ 队列积压时怎么排查
- Kafka 积压突然飙升时怎么排查
- Kubernetes Pod Pending 时怎么排查
- Kubernetes CrashLoopBackOff 时怎么排查
- Kubernetes Pod Pending 时怎么排查
- Kubernetes CrashLoopBackOff 时怎么排查
- RabbitMQ 队列积压时怎么排查
- Redis RT 抖动时先看命令还是网络
- MySQL 连接打满时要先判断哪几类来源
- MQ 积压排查为什么先看生产端不一定对
延伸相关入口如果你已经确认故障更偏应用层,例如 GC、CPU 或线程池问题,继续到应用运行时排障专题会更高效;如果你想系统补存储、缓存、消息和检索原理,回到数据与中间件总览会更合适。