wmap server

凌晨三点，我盯着终端里滚动的日志，wmap server 又吞掉了三百个并发请求。这玩意儿不是地图服务，虽然名字听起来像。它是我们内部跑批任务的调度核心，每天凌晨两点开始，把几千个数据管道像发牌一样分给二十台工作机。你要是见过它卡壳的样子就懂了——队列堵到五千，内存飙到百分之八十，日志里全是红色的 timeout。

一开始我怀疑是代码写得太烂。毕竟接手的时候，前任留下的注释只有一句“别动这里，会炸”。后来翻了三天源码，发现瓶颈根本不在调度逻辑，而在状态同步。每台工作机完成一个任务，都要往中心节点写一条确认记录。高峰期每秒几千次写入，MySQL 扛不住，锁竞争能把响应时间拖到三秒以上。我试着换成 Redis 做中间层，结果数据一致性又出问题——任务完成了，状态没更新，调度器重复派发，下游的同事半夜打电话骂我。

后来我干脆把同步机制砍了。改成推拉结合：工作机完成任务后主动上报，调度器不再等待确认，而是每十秒扫一次心跳表。超时的任务重新入队，但标记上“疑似重复”的标签。下游处理逻辑加个幂等校验，重复执行也不怕。改动上线那晚我蹲在机房，手心全是汗。结果第二天早上看监控，队列峰值从五千降到八百，平均延迟从两秒掉到两百毫秒。

有意思的是，这个系统真正的瓶颈从来不是性能。是业务方总在深夜加急任务，优先级还设得特别高。调度器按优先级排序，高优任务插队，但低优任务长时间饿死，数据越积越旧。有次财务跑月度报表，等了六个小时没出结果，因为中间被插了二十多个“加急”的实时风控任务。我调了权重算法，给每个任务算个“年龄惩罚”，等得越久优先级越高，总算把这事摁住了。

现在这个 server 已经跑了八个月，没出过大岔子。我偶尔会在凌晨四点半打开监控页面，看着那些绿色的小方块像呼吸一样亮灭。没人知道它每天处理多少数据，也没人关心它背后的调度策略。但只要它在跑，整条数据链路就稳稳当当的。有时候我会想，这种系统就像城市的地下管网，平时看不见摸不着，一旦堵了，大家才意识到它的存在。

不过说实话，我挺喜欢维护它的。那种半夜被叫醒、盯着日志找问题、最后发现是个逗号写错了的时刻，比写一百行新功能都刺激。wmap server 不完美，它的日志里还躺着几千条 warning，但至少它现在学会了自己消化大部分问题。这比什么高可用架构都实在。