四十秒的任务撞上三十秒的超时 8 月 11 号，我们的工单自动处理 Agent 上线一周后，监控上出现一条难看的曲线：任务失败率 4.7%，失败原因几乎全是 UpstreamTimeout。 查了一下，原因很直白——这个 Agent 平均执行 11 秒，但 P99 是 41 秒。而我们网关的超时是
一次发版，37 个跑了两小时的任务全没了 五月底的一次例行发版，我们的合同审核 Agent 服务重启。重启完没多久，业务部门来问："我昨天下午提交的那批合同怎么一直显示'审核中'？" 查了一下，那次重启时正在执行的 37 个长任务全部丢失，其中最长的已经跑了 2 小时 17 分钟，完成了 60 多个
风控要在 200ms 内给出决策，而模型要 150ms 我们电商风控原来是一套 Drools 规则引擎，几百条规则，命中就拦截。去年底开始加模型：用用户最近 5 分钟的行为序列算实时特征，喂给一个轻量模型打分，超过阈值就拦截。 难在时间预算。风控决策必须在用户下单后 200ms 内返回，而模型推理本
同事甩给我一个跑了 25 分钟的同步接口 上周三下午，做商品中心的小赵在工位上喊我："哥，我这个批量生成接口本地跑得好好的，一上预发就 504，你帮我看看。" 需求不复杂：运营上传一个 5000 行的商品 Excel，每行调一次大模型生成营销文案，全跑完导出结果文件。他写的是同步接口，一个 for
我们的交易系统原来用定时任务把 MySQL 数据同步到数据仓库，每 5 分钟跑一次，分析师看到的总是"5 分钟前的旧账"。业务方要实时大屏，等不了。于是用 Kafka 搭了一条 CDC 驱动的实时数据管道，端到端延迟从 5 分钟压到 800 毫秒。 CDC 接入：让数据库自己说变化 定时拉全量太低效
定时任务从 Quartz 搬出来的契机 老系统用 Quartz 集群，任务一多就出现重复触发，两台机器各跑一遍，数据算重了还得手工修。排查发现是 Quartz 的数据库锁在高峰期没兜住。今年做调度中台，我在 XXL-JOB 和 Elastic-Job 之间选，两者都能解决分布式场景，但设计取向不同，
背景：ZooKeeper 又成了单点隐患 七月中我们的 Kafka 集群（3.2 版本，还跑在 ZooKeeper 上）遇到一次 ZK 会话超时，导致整个集群控制器选举卡了 90 秒，消息生产大面积抖动。ZK 那套独立组件既要单独运维、又要和 Kafka 版本对齐，一直是心腹大患。Kafka 3.3
事故：用户收到两笔重复的退款 五一后第一天，客服转来一个投诉：同一笔订单退了两次款。查 MQ 消费日志，发现退款消息被消费了两次。RocketMQ 的「至少一次」投递语义意味着重复消费必然发生，幂等没做好的锅，得我们自己背。 排查：为什么恰好重复 消息体里其实带了唯一的 refundId，但旧代码直
一次奇怪的吞吐量瓶颈 大促前给订单流水 topic 扩分区，从 12 个加到 48 个，本以为吞吐能线性提升，结果生产端 P99 延迟不降反升，监控上看到 broker 端请求队列开始堆积。翻了半天才意识到：分区数过了拐点就是负担，不是越多越猛。 这事其实之前踩过一次。那回我们是 consumer
注册中心抖动，推送延迟到了 8 秒 去年我们把配置中心/注册中心从 Nacos 1.x 升到 2.0，起因是一次线上抖动：一个服务下线，但网关隔了 8 秒才感知到，期间一大波请求打到了已死的实例。翻 Nacos 1.x 的源码才知道，它用的是客户端 10 秒一次 HTTP 轮询去拉变更，服务端有了新
