-
放量就 429 账单还暴涨:大模型 API 生产化避坑
我们给一个功能接入大模型 API:用户提交内容后端实时调 LLM 分析返回结果,灰度时一切美好响应又快又准。可一旦放量真实流量涌进来两件事同时炸了:一是接口大面积失败、日志铺天盖地 429 Too Many Requests 被服务商限流了,二是月中财务找上门说这功能的 API 费用几天就烧掉一大笔预算照势头月底要爆表。一边大量请求失败一边花钱如流水,我被这又贵又不稳的双重暴击逼着重新审视调用姿势…... -
日志撑爆磁盘服务全线崩:磁盘写满避坑复盘
一个安静的凌晨告警把我从睡梦炸醒:核心服务全线挂了,不是某个接口慢而是所有功能一起瘫痪,下单失败、查询报错、连健康检查都过不了。迷迷糊糊登上服务器想看日志,第一条命令就当头一棒:cannot create temp file: No space left on device,磁盘满了,df -h 一看根分区赫然 100% 一个字节空闲都没有。可这台机器磁盘几百 G 平时用量才三十几,怎么一夜就被塞…... -
偶发 connection reset:连接池复用死连接避坑
有个服务调用下游接口平时好好的,可总会偶发地毫无规律报一个错:Connection reset by peer——连接被对端重置了,频率不高几百次请求一两次、重试又能成功,起初没太当回事,可流量增长后积累的失败量越来越扎眼。这个错最磨人的就是随机性:同样的代码同样的接口绝大多数都好好的偏偏隔一阵冒一个失败。抓了好久包对了好久日志才慢慢拼出真相,藏在一个我从没留意的细节里:这些失败几乎都发生在一段时…... -
数据库很闲却拿不到连接:连接池耗尽避坑复盘
有个服务平时跑得好好的,可一到流量高峰就突然集体卡死:大量请求超时,日志清一色报 Connection is not available, request timed out after 30000ms——等了 30 秒都没从连接池拿到一个数据库连接。诡异的是数据库本身一点不忙,CPU 内存都很闲、慢查询日志干干净净,明明数据库很空闲我的服务却拿不到连接,问题显然不在数据库而在那个连接池上。盯着监…... -
用户A看到了用户B的信息:ThreadLocal 串号避坑
这是我职业生涯里最惊出一身冷汗的一次线上事故。我们用 ThreadLocal 存当前登录用户的上下文——请求进来时在拦截器里把用户信息塞进 ThreadLocal、后续业务随时取当前是谁,用了很久一直稳稳的。可某天客服收到一个让所有人头皮发麻的投诉:一个用户登录后在自己的页面里看到的却是另一个陌生用户的姓名手机号订单,用户信息串了——这涉及隐私泄露性质极其恶劣。连夜拉日志排查才拼出全貌:Web 服…...
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×