这篇是2026年1月12日的个人工作复盘——不想写成那种年末总结的流水账就是老老实实记录一个项目收尾日。这天的主线任务是微服务链路优化项目的最后冲刺中间穿插了一场线上告警排查、一个技术评审会、若干次联调扯皮。2026刚开年这个节点恰好把上一阶段的问题都翻出来了挺值得记一笔的。如果你也是做后端或者全栈开发这篇总结里涉及的连接池参数调整、缓存穿透整治、接口约定复盘都是从真实事故里长出来的经验。我会把排查思路、调整参数、验证方式都写清楚方便你直接拿去对照自己的系统看。1. 今日总览收尾阶段的一天长什么样1.1 一条凌晨告警把节奏打乱了计划里今天上午是纯开发时间把链路优化的最后一个模块收尾。结果早上九点半刚到工位手机连续震了十几下——监控平台推送了线上告警商品服务的一个核心接口P99延迟从180ms飙到1200ms左右错误率从0.01%爬到0.8%。这种凌晨积累、早高峰爆发的延迟问题大概率不是偶然抖动。我快速打开监控面板先看服务QPS曲线没什么明显尖峰再看CPU和内存都在安全水位最后往慢SQL和Redis慢日志方向查果然在Redis慢日志里发现了猫腻——一批缓存过期后大量请求直接穿透到数据库把连接池打满了。处理这类问题的第一原则是止损优先。我先把商品服务里几个热key的过期时间临时拉长到12小时错误率五分钟内回落到正常水平。然后把完整的排查思路记录到工单里等忙完手头的事再深挖根治方案。这类告警提醒了我一件事收尾阶段别只盯着新功能系统稳定性是上线的最后一条防线。上午九点半到十点半整个时间段都耗在这个事故上了。1.2 任务列表与现实的对账复盘一天的工作第一步是把“计划任务”和“实际发生”做成一张对照表。我今天早上列的To-Do有七项最终完成了五项一项被事故挤掉挪到明天一项在评审会上被推翻了。计划事项实际状态原因完成链路优化模块收尾完成自治愈方案落地补了单元测试排查线上接口延迟告警完成热key临时过期处理根因定位准备下午技术评审会材料完成整理了三个方案的对比数据修复联调中的接口返回格式问题完成定位为字段类型不一致已联调通过重构订单服务缓存代码未完成被上午告警占用时间挪到1.13清理临时日志脚本未完成顺延到明日复盘本周技术债务清单完成输出一页纸清单附带优先级建议做这种对照不是为了自我批判而是为了搞清楚时间都花在哪儿了。对比一看就明白计划外的线上问题直接占掉80分钟的整块时间而临时打断带来的是注意力损耗——每次切上下文至少需要五到十分钟才能重新进入深度状态。所以任务排期一定要预留20%的缓冲带不然一旦出事整个下午的计划全得跟着变。2. 踩过的三个技术坑参数、缓存与日志2.1 连接池参数调整带来的连锁反应上午告警的根源是数据库连接池被打满。一开始我怀疑是数据库性能不行看监控才发现连接数早就超过阈值了——数据库连接数一直在600左右缓慢爬升而连接池maxActive配置的是200理论上不会超怎么还会打满后来查代码和配置才知道这个服务在代码里创建了三个独立的数据源每个数据源单独配置了最大连接数三个加起来才是真实连接峰值。而监控面板只能看到数据库侧的总连接数不能反映线程池内部等待数。连接池满了以后后面所有等待连接的请求会堆积在线程池队列里直接拖垮接口响应速度。这次我先做的是止损重启了服务让连接池清空把热key的过期时间拉长。根治方案是写一个动态连接池监控脚本定时抓取jstack线程状态检测线程BLOCKED和WAITING数量超过阈值就推送告警。顺带分享一个值得记录的操作连接池参数不是越小越安全也不是越大越好。从现象推回去连接池分配的策略要看请求处理时长T和请求并发量C大致的连接池估算公式是连接数 ≈ 并发请求数 × 单个请求平均耗时(秒) / 期望响应时间(秒)按这个公式反推我们服务目前的并发场景连接池60~80就够了。和DBA确认后我把三个数据源的maxActive分别调整为60、40、30并加上最小空闲连接数、连接超时时间配置出来后实测P99稳定在150ms左右。这套参数组合之前踩过坑以后再遇上类似问题可以直接拿来用。2.2 缓存穿透布隆过滤器的二次实践Redis慢日志查到最后发现凌晨的一波热点数据过期直接把请求压垮了。这类问题的正式名字叫缓存穿透——大量请求请求一个不存在的key或者刚过期的key直接把流量打到了数据库。处理穿透问题的等级是层层递进的缓存空值最简单到互斥锁防击穿再到布隆过滤器过滤不存在的key。这次我图的是一劳永逸直接上了布隆过滤器。布隆过滤器的基本原理是对一个key做多次hash把结果映射到一个大位数组里。判断key存在时如果位数组中对应位置都是1就认为key可能存在如果任何一个位置是0就肯定不存在。这里有个核心权衡布隆过滤器会误判“存在但实际不存在”但绝不会漏判“实际存在”。误判率可以通过位数组长度和hash函数个数来控制。实现起来也不复杂在项目里引入一个布隆过滤器插件启动时把商品ID列表加载进过滤器请求进来先判断这个key在不在过滤器中不在就直接返回空结果不进Redis也不进数据库// 请求入口处拦截 public ProductInfo getProductInfo(String productId) { if (!bloomFilter.mightContain(productId)) { return null; // 不存在的商品直接返回 } // 正常走缓存数据库查询 ProductInfo info redisCache.get(productId); if (info null) { info productMapper.selectById(productId); redisCache.set(productId, info, 10 * 60); } return info; }注意布隆过滤器在商品系统里要注意数据增量同步新商品上架时必须往过滤器里也加一份不然会误杀新商品流量。第一次同步全量数据时也要选在低峰期批量写入过滤器要控制在几万条每秒的水平防止写入耗时太长影响业务。这点在文档里通常不会特别写但实操时一定会碰到建议提前做好同步逻辑。顺带留一个复盘笔记布隆过滤器基于内存实现服务重启后位数组会清空。因此重启时要么做持久化要么在服务启动时用异步线程重新加载全部key。我当时图省事直接全量加载五十万条数据大概花了两分半钟其实可以接受但如果你的系统数据量到了千万级这个方法就要优化了否则服务启动时间会非常感人。2.3 日志淹没有效告警越查越迷糊下午评审会之前我顺手整理了这个链接优化项目的线上日志发现了第三个值得记录的坑日志量大到完全淹没了有效信息。这个服务的业务日志INFO级别每小时就有几百MB中间夹杂着大量重复的错误堆栈真正的告警反而被挤到角落里。排查问题靠的是日志但日志太多等于没有日志。我翻项目代码发现很多地方直接用了System.out或者logger.info输出参数对象生产环境还在跑DEBUG级别。这应该是在联调阶段留下的上线时忘记关掉了。我彻底做了一次日志清理把日志级别调整为INFODEBUG只允许在测试环境开启所有不打印参数完整值的代码改为输出关键字段涉及敏感信息的做脱敏处理给业务日志加了requestId用它可以串联一次请求的完整链路排查问题时能省一大半时间对重复的异常堆栈做汇总相同错误输出到单独的error统计日志中错误率超过阈值就告警。这套组合下来日志量下降了大约60%告警的有效性明显提升。排查线上问题时打开日志不会再有“大海捞针”的感觉直接按requestId搜索就能看到调用链全部经过。3. 两场会议与一次协作修复3.1 技术评审会把“我觉得”变成“数据说话”下午两点约了一场技术评审会讨论的是链路优化的核心模块要不要沿用现有的同步调用方案。会上开发同学提出要换成异步消息方案理由是同步调用的耗时太高。这个提议从直觉上是有道理的但他给不出来数据——耗时高多少高峰QPS是多少换成异步后业务上可接受的延迟是多少如果评审会只是比嗓门大那就失去了意义。我现场打开监控面板投屏把调用链路的耗时分布表拉出来同步方案P99耗时320ms其中下游服务耗时280ms占总耗时87%改用异步后调用方可以先行返回在用户体验上感知会更好。但商品服务的核心接口绕不开数据一致性异步方案要引入分布式事务复杂度指数上升维护成本也跟着涨。最后讨论出的结果是用折中方案把链路中的查询操作并行化用CompletableFuture把三个不依赖的数据查询同时发出去串行变并行总耗时能从320ms压到150ms左右。这个方案不用改架构不用引入额外的消息中间件开发量也小。评审会给我的收获是技术选型必须拿数据来说话。别拍脑袋说“性能太差”要能说明差在哪里、差多少、优化后预期效果是多少。这就是工程师和资深工程师的分水岭。3.2 联调中的接口约定问题扯皮半小时才定位评审会结束后接着和前端的同学联调一个列表页接口。前端说我们的接口返回的字段类型不对——他拿到的userId是字符串但文档里写的是整数渲染时数字精度出问题。我查了一下确实是后端代码里返回的是String类型但Swagger文档标注的是Long。这类问题的根因是定义接口时返回字段的类型没有经过严格对齐写文档和写代码的人没有确认清楚。多出来的那半小时纯属前端和后端在互相确认“你那边到底该是什么类型”这就是典型的沟通成本。解决方式是约定了一个规则接口文档使用统一的API定义平台管理任何字段变更必须在平台里发起变更同步到前后端各自的模块。同时补了一个自动化校验——在CI阶段跑接口契约测试文档和代码不一致时直接构建失败。这招看着简单落实之后联调阶段因为字段类型问题扯皮的次数基本归零。4. 个人效率工具箱今天顺手优化的三个小事4.1 本地开发环境提速JVM参数调优下午写代码时发现本地启动项目要花两三分钟经过反复排查主要是本地分配的内存不够频繁Full GC导致启动极慢。我打开任务管理器一看同时跑着IDEA、Chrome、微信、企业IM、数据库客户端16G内存一直被占满。解决方式是新建了一个IDEA的Run Configuration给JVM加了启动参数限制内存-Xms256m -Xmx1024m -XX:MaxMetaspaceSize512m不要小看这个配置本地开发环境给JVM设置过大的堆内存反而会拖慢启动速度——系统需要花更多时间进行内存分配和GC。把最大堆限制在1G以内本地开发足够启动速度能提升30%以上。同时我把Chrome的大标签页都收起来省下来的内存给Docker容器用。4.2 写了一个一键清理临时文件的Shell脚本今天还趁着间隙写了一个小脚本用来一键清理项目目录下的临时文件——之前总是要手动删target目录和IDE缓存烦了。#!/bin/bash # 清理当前项目临时文件 echo 开始清理... find . -type d -name target -exec rm -rf {} 2/dev/null find . -type d -name .idea -exec rm -rf {} 2/dev/null find . -type d -name node_modules -exec rm -rf {} 2/dev/null echo 清理完成target、.idea、node_modules 已被移除这脚本的价值不在于代码本身而在于它符合“把重复的事情自动化”的原则。每天收尾时跑一次能避免一个很大的坑旧构建产物和旧依赖被误当成新代码打进了包里。一次因为target目录没清干净导致的线上事故让我养成了这个习惯。4.3 快捷键和窗口管理把碎片时间利用起来今天被会议和联调打断了好几次重新进入专注状态特别费劲。我在下午试了一个方法把常用的开发工具窗口布局固定下来IDEA在左侧终端在右侧浏览器在上方独立桌面。切换任务时用快捷键直接跳转比鼠标点图标快了一半时间。这方法听起来不起眼但一天被各种事件打断十几次每次省下十几秒积累下来就是十分钟左右的专注时间。对于重度搬砖来说这个收益不小了。5. 明日计划与对“总结”这件事本身的思考5.1 明日To-Do把今天欠的债还上完成订单服务缓存代码重构合并到主分支编写动态连接池监控脚本的单元测试和说明文档整理本周技术债务清单发给项目组同步排期把布隆过滤器的持久化方案补充到项目文档中避免后续踩坑。5.2 写总结的意义不是记录而是排练我现在越来越觉得写“总结”不是为了存档而是通过文字把一个复杂系统的运行过程重新在脑子里跑一遍。今天这个日子很有代表性有事故、有决策、有协作、有平常常被忽略的效率细节。复盘之后我对整个链路优化的理解比早上深了一个层次尤其是连接池参数调整和布隆过滤器的方案。如果你也在写类似的项目总结或者日志复盘我的经验是别记流水账要记决策背后的理由、排查问题的路径、参数调整的依据。三个月后回看这些内容它们不是记录而是你的个人决策库。每次遇到相似问题直接翻出旧文档来对照节省的时间远超写总结花掉的时间。踩过几次坑之后你会发现把经验沉淀下来的动作本身就是效率提速的一部分。