三月中旬的一个周五晚上，林晨坐在书房里，面前是两块屏幕。
左边屏幕是投资系统的监控面板，绿红交替的数字显示着各子策略的运行状态。右边屏幕是代码编辑器，光标停在一行注释上。
他已经盯着这行注释看了十分钟。
问题是这样的：金融科技小组的李婷在做风控模型的时候，遇到了一个性能瓶颈。原始数据需要做特征工程，但特征计算的延迟太高，导致实时性不够。李婷试了几种优化方案，效果都不理想，最后找到了林晨。
林总，这个特征计算的延迟有200毫秒，但我们的要求是50毫秒以内。我试了缓存、预计算、异步加载，都不行。
林晨看了一眼代码，立刻意识到问题所在：特征计算用了一个嵌套的SQL查询，每次请求都要查两次数据库。这在离线场景下无所谓，但在实时场景下就是性能杀手。
他本能地想自己写一个优化方案——毕竟这是他最擅长的事情。投资系统的特征计算延迟只有15毫秒，他用的是自己设计的内存数据库加增量更新的架构，这个方案完全可以用在金融模型上。
但他刚要把方案写下来，又停住了。
如果把方案直接给李婷，她的问题解决了，但她不会学到东西。下次遇到类似的性能问题，她还是会来找他。
他想起苏婉那天的提醒：你是Leader，不是救火队员。
于是他换了一种方式。他在代码旁边加了一行注释：问题在SQL嵌套查询，每请求两次数据库访问。想想怎么把数据库访问减少到零次。
然后他把代码推回给李婷，附了一条消息：别急着优化SQL。先想想怎么让特征计算不需要访问数据库。提示：投资系统是怎么做的？
半小时后，李婷回了一条消息：内存缓存？把特征预加载到Redis里，每次请求直接从缓存读？
对了一半。林晨回道，缓存只是存储，你还需要增量更新。不然数据变了，缓存就是脏的。
又过了一小时，李婷发来了一段代码：林总你看这样行不行？特征预加载到内存，数据变更时通过消息队列增量更新。我估算了一下延迟，大概20毫秒。
林晨看了代码，点了点头。方案没有他投资系统的方案优雅，但核心思路是对的——零数据库访问，增量更新。性能从200毫秒降到20毫秒，远超目标。
可以。再考虑一下：如果某次增量更新失败怎么办？缓存和数据库不一致
（本章节未完结，点击下一页翻页继续阅读）
正在加载...