后端架构师三步调优，服务器吞吐量翻倍

　　去年一月份面个后端架构师，会议室空调滴水，滴答滴答砸在简历上，那哥们儿把简历在桌上转了半圈，转了三次才停住。我原以为他是紧张，结果他开口第一句就说：“你们这吞吐量，三步就能翻倍。”

　　我当时差点笑出声。三步？这词儿现在面试都成万能钥匙了？上回有个候选人说“三步搞定高并发”，结果连JVM参数都调不明白。但这次这哥们儿转笔的节奏挺稳，简历上写过“主导过百万级订单系统重构”，我忍了忍，没直接怼。

　　我笔停了。换数据库？这操作我见过，但敢在面试里当“第三步”说的，他是头一个。他解释：“你们现在用MySQL，主从延迟高，分库分表后跨库JOIN麻烦。换成TiDB，分布式事务，水平扩展，吞吐量至少翻一倍。”

　　我盯着他简历上的“TiDB”字样，突然想起上周技术部开会，CTO拍桌子骂：“谁再提换数据库，自己写离职申请！”当时是因为有个团队非要上ClickHouse，结果数据迁移搞了半个月，性能反而降了20%。但眼前这哥们儿说得挺顺，像是真干过。

　　我问：“TiDB的GC策略你调过吗？TiKV的Region分裂参数怎么设？”他愣了下，转笔的手停了：“GC策略...默认的就行吧？Region分裂...不是自动的吗？”

　　我笑了。果然，三步调优的“第三步”，他连参数都没摸过。但前两步他确实懂——拆服务时他提到“用Service Mesh做服务治理”，加缓存时提到“用本地缓存+分布式缓存的混合模式”，这些细节不像背的。我低头看简历，发现他上家公司规模不大，日活也就几十万，离“百万级订单”差得远。

　　走廊有股消毒水味，前台在大声打电话，说“快递放前台就行”。我抬头：“你说三步调优，那如果第一步拆服务后，服务间调用链变长，延迟增加怎么办？”他眼睛亮了：“用gRPC的流式调用，或者异步消息队列。”又补了句：“但得监控调用链，用SkyWalking或者Pinpoint。”

　　这回答挺实在。我原以为他会说“加网关”或者“上服务网格”，结果他提了具体工具，还知道要监控。我翻简历，发现他写过“熟悉APM工具”，但没写具体用哪个。这哥们儿有点意思——该说的说，不该说的藏得挺深。

　　后来聊到压测，他说用JMeter做过全链路压测，能模拟2000并发。我问：“2000并发时，你们的QPS多少？”他算了算：“大概...800？”我皱眉：“800？这吞吐量连翻倍的起点都够不上。”他挠头：“所以得调优啊...”

　　我突然想起上周面试的另一个候选人——那哥们儿简历写“精通高并发”，结果问“如何优化TCP连接”时，他说“用长连接”。我问“长连接怎么管理？心跳机制怎么设？”他支支吾吾说“用框架自带的”。后来查他项目，发现他所谓的“高并发”系统，日活不到5000。

　　回到眼前这哥们儿，我问：“你说三步调优能翻倍，那如果现在系统吞吐量是1000，调优后到2000，你觉得最可能卡在哪一步？”他想了想：“第二步，加缓存。缓存命中率上不去，或者缓存穿透，性能反而会降。”

　　这回答我满意。很多人吹“三步调优”时，只说好处不说风险，他能想到缓存的坑，说明真干过。我低头看表，面试已经40分钟，超了10分钟——本来只打算聊20分钟的。

　　最后我问：“如果让你选，你会先做哪一步？”他没犹豫：“第一步，拆服务。但得先评估现有系统的耦合度，如果耦合太高，拆了反而更乱。”又补了句：“其实三步不是固定的，得看系统现状。比如你们现在如果缓存用得好，可能第二步不用动，直接换数据库就行。”

文章配图，仅供参考

　　对了，那哥们儿最后没来——他拿了另一个offer，薪资比我们高20%。我倒不遗憾，这种有思路、不瞎吹的人，去哪儿都能混好。就是可惜了，下次面试得准备点更狠的问题，别再被“三步调优”这种话术糊弄了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!