第124章 工作琐事（2/2）

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

他回到工位，调出上游业务系统的数据写入监控。把凌晨三点到早上九点之间每十分钟的写入量统计拉成柱状图，图一出来答案就浮在水面上了——上游有一个定时采集任务，每天凌晨三点到早上九点之间每隔四十分钟执行一次，每次任务执行时会在十秒内向数据库批量插入大约三十万条采集数据，十秒内的瞬时写入速率是平时峰值的六倍以上。三十万条记录的瞬时写入峰值就像一个浪头，增量同步通道必须在下一个四十分钟周期到来之前把这个浪头产生的积压全部消化掉。正常情况下，通道的带宽够用，积压可以在十分钟内被逐渐消化掉，但这十分钟的消化期就是监控系统看到的延迟尖峰。

为了进一步验证，他分别对比了上游采集任务和下游延迟尖峰的时间戳列表，把凌晨三点到早上九点之间的九个采集任务执行时间与九个延迟尖峰的起始时间对齐，偏移量均不超过一分钟。这就对上了。延迟的根源不在同步通道本身，而在上游的周期性批量写入。同步通道只是忠实地反映了这个写入节律，把上游的周期性压力转化成了下游的周期性延迟曲线。他还找到了为什么这个问题在之前几个月的监控里没有被明显放大的原因——最近业务扩展后采集终端数量增加了百分之四十，同样的批量写入任务载荷变大了，延迟尖峰从原来的一分钟左右拉长到了将近两分钟，振幅翻倍才触发了P1告警阈值。

十一点二十分他把完整的排查结论整理成一份报告，附上时间戳对照表和上游采集任务配置截图，发给了运维组和上游业务组。核心结论是延迟尖峰的根源在于上游定时采集任务的批量写入模式，瞬时写入速率超过同步通道的平滑带宽，建议将批量写入策略改为流式分批提交，将三十万条记录的瞬时峰值分摊到十分钟内逐步写入。

下午三点，上游业务组的同事回复确认了排查结论，开始在测试环境里验证分批提交策略。林泠靠在椅背上转了转脖子，把今天这九次延迟尖峰的完整数据打出来夹进笔记本的工作备忘页里，在析完全一致——划定时间窗口，锁定异常波动节律，提取周期特征比对已知调度任务，排除定时任务、缓存、日志、备份四个常见变量，定位上游写入模式的周期性节律。

写完他放下笔，站起来走到窗边。窗外的阳光很好，办公楼的玻璃幕墙反射出一片晃眼的白光。