工作总结
计算机工作总结。
年初接手那个数据采集模块时，我就知道这是个烫手山芋。代码仓库最近一次提交是一年半前，文档只有一行“本模块负责数据接入”——跟没写一样。更邪门的是，前任离职前在注释里留了句“祝你好运”。我当时就想，完了，这坑肯定不小。
果然，五月中旬的一个凌晨，告警跟炸了锅似的。某数据源推送量从每分钟三千条飙到八万，我们那个消费线程池直接跪了，消息积压堆到两百多万。我的第一反应是扩容——加节点，先把积压干掉再说。折腾了半小时，积压降下来了，但老年代内存占用一直往上窜，GC日志里Full GC的频率从每小时一次变成每十分钟一次。这不对。
当晚我干了件蠢事：先怀疑是自己的代码有内存泄露，把刚上线的一个功能回滚了，没用；又怀疑数据库连接池配置不对，改了三次参数重启了两次，还是没用。凌晨三点，我蹲在机房里盯着监控，突然想到：是不是该看看堆转储？之前总觉得堆转储文件太大，分析起来费劲，就一直拖着。那天实在没招了，硬着头皮dump了一个4.8G的文件，用MAT打开，等了好几分钟才出来结果。一看，有个第三方解析库的ThreadLocal里缓存了上百万个临时对象，线程复用时不清理。这简直——怎么说呢，当时我对着屏幕骂了句脏话。这个库用了两年，功能测试全过，谁能想到边界条件下有这种雷？
第二天我跟领导汇报，他说“那你赶紧修啊”。修倒是简单，用装饰器把解析前后强制清理一下就行。但我额外花了一整天，把生产环境所有依赖的三方库都列了个表，挨个做了压力测试和内存分析。有些同事觉得我小题大做，我说“你们没熬过那个凌晨，你们不知道那种想砸键盘的感觉”。后来这个清单成了团队的上线前置检查项。
下半年的重头戏是历史数据归档模块的重构。老模块的设计思路大概是“能跑就行”——全表扫描加逐条处理，数据量上亿后一次跑24小时还跑不完，而且频繁锁表，白天业务一写入就死锁。我接手后第一件事不是写代码，是先跑了一遍老模块，记录下每一步的耗时分布。结果发现：80%的时间花在逐条delete和索引维护上。
那我就想，能不能改成批量处理加分区交换？具体怎么做：利用自增主键的范围，每10万条作为一个批次，并行提交到线程池。但这里有个坑——我一开始设的批次大小是20万条，想着减少批次数量能快，结果跑起来年轻代GC频繁，因为每个批次加载的数据量太大，对象还没处理完就被GC回收了，反而更慢。后来试了5万条，线程切换开销又上去了。折腾了两天才找到平衡点：10万条加4个并行线程。从27小时降到3小时20分。你以为这就完了？上线第一周，有个分区因为边界数据问题导致重复归档，差点把生产数据搞乱。我又加了分布式锁和幂等校验，最终稳定在2小时18分钟。
有人说你这个数字真漂亮，是不是编的？我跟你讲，漂亮是因为我踩过的坑没写进PPT里。比如临时禁用索引这个操作——归档时我先把目标表的非聚集索引禁掉，等数据写完再重建，写入速度直接翻了五倍。但第一次干的时候，重建索引忘了开并行度，跑了40分钟，把业务高峰期的写入堵了。领导打电话过来问怎么回事，我说“我的锅，索引重建没优化”。后来我专门写了个脚本，重建索引时自动检测负载，低峰期才跑。
团队协作那块，说件真事。七月份，三个下游系统要联调一个新接口，时间卡得死。其中一个系统的负责人是个老资格，他觉得我们的方案改动太大，坚持要用老接口加适配层。那天下午在会议室，他拍着桌子说“你这是过度设计！上线出了问题谁负责？”我也急了眼，回他“那你就继续忍受24小时跑不完？”场面一度很僵。
后来我冷静下来，做了件事：把两种方案的代码改动范围、测试用例数、回滚时间、性能预期，全部列成一个表格，用红黄绿标出风险等级。第二天一早我敲他办公室门，把表格递过去，说“你看看，哪里不对咱们改”。他看了十分钟，指着其中一项说“你这回滚方案不完善，少了数据校验步骤”。我当场加上，他又提了两个边界条件。最后我们选了个折中——核心逻辑用新架构，外围保留老接口的兼容代码，加个@Deprecated注解，慢慢切流量。那个老哥后来还请我喝了瓶可乐，说“你小子还行，至少听劝”。
那场争执让我想明白一件事：技术决策没有完美的，只有当下团队能接受、风险可控的。比写代码更难的，是让跟你意见不同的人愿意坐下来一起解决问题。
对了，还有件小事。那个雨后的清晨，我还在赶地铁，客户方的一个运维大哥打来电话，说“兄弟，你们那个接口今天跑了四百万笔，稳得很，谢谢啊”。挂了电话，我在地铁上站了半小时，心里说不上激动，就是觉得——干这行，有时候一句“稳得很”比什么绩效A都管用。
今年我给自己补了两门课：一是Linux的I/O栈，因为总遇到写放大问题；二是分布式事务的最终一致性方案。学习方法很简单——复现问题，然后逐层往下挖。比如写放大，我先用perf和blktrace抓系统调用，发现是MySQL的redo log刷盘太频繁。解决方案不是改代码，而是先调整了innodb_log_file_size和innodb_flush_log_at_trx_commit参数，配合业务层的批量提交阈值从100调到1000。测了三天，TPS从800升到2100，磁盘IOPS降了一半。有人问“你怎么知道调这些参数”，我说“不知道，一个一个试的，试错了就回滚，记录下每次的结果”。这法子笨，但管用。
明年我给自己定了两个目标，不画大饼：一是把全链路追踪系统真正跑起来，现在跨服务调用出了问题，定位一次要半天，太丢人了；二是整理出一套压测模型，每个模块上线前必须跑通基线，不能再靠“感觉没问题”就发布。
技术这东西，越干越觉得没那么玄乎。说白了就是：遇到问题别慌，一步一步拆；跟人吵架别上头，拿数据说话；自己踩过的坑，记得写下来，别让后面的人再踩一遍。这大概就是一个老一线工程师最实在的本事。
- 更多精彩工作总结内容，请访问我们为您准备的专题：工作总结
