十月十六号:一个线程池配置引发的连锁故障 那天下午三点,监控系统开始报"下单接口超时率 35%"。我打开看的时候,发现不只是下单——商品详情、购物车、用户信息,几乎所有接口都在超时。网关的活跃连接数从平时的 200 涨到了 7800。 整个服务集群像是被什么东西卡住了。 现象:线程全在 WAITIN
凌晨两点的告警:消息积压 12 万条 6 月 18 号大促那晚,我睡到两点被电话叫醒。监控群里刷的是一条 RocketMQ 的告警:order_pay_topic 消费 TPS 从平时的 800 掉到了 30,积压量 12 万条还在涨。 赶紧登机器看日志,消费者进程活着,CPU 只有 11%,但日志
同事问了个我答不上来的问题 2 月中旬,组里做短信发送模块的改造,同事在配置线程池时问我:corePoolSize 用完之后,是立刻扩容到 maximumPoolSize,还是先往队列里塞? 我当时脱口而出"先扩容到 max"。说完自己就心虚了,因为印象里看过"队列满了才会扩"的说法。答不上来的问题
上午十点,接口全部超时 5 月 8 号上午十点整,监控告警连着响了:订单服务的接口 P99 从 80ms 涨到 30 秒(超时阈值),成功率掉到 12%。登录机器看,进程还在,CPU 只有 6%,内存正常,但所有请求都在超时。 第一感觉是数据库挂了。查了 MySQL 监控,QPS 只有平时的三分之一