前言

一个页面，加载耗时1.3分钟，分析后发现用的O/RM，我记得12306以前爆是因为用的hibernate，而且没用好。

O/RM有各种硬伤，但总是有优化办法。我改进后测试1秒。

痛点

澳大利亚很多政府/企业财年结束（6月30日）便需要进行一些年度操作，譬如给客户发送年度报告等等。

澳大利亚最大的养老金管理也不例外，需要给数百万用户发送一个流水账单（PDF文件格式），根据多年来的观察和官方的说明，一般需要等到9月底到10月初，这意味着需要起码2个月来处理。

分析

简单计算，意味着顺序处理的话，大概每秒完成一个客户，听起来不算慢。

大家会觉得，一年的流水，多则几百条记录，取出来0.4秒，生成PDF是0.5秒，发送0.1秒，那相当合理。

在这个系列操作中，单个业务的瓶颈可能是：

• 数据获取/计算
• PDF生成
• Email发送

优化

最佳的优化，彻底理解业务逻辑后作出相应的改动。在没有理解业务逻辑之前，我们一般提供效率的做法可能有：

• 分而治之：多个服务器并行操作，每个负责某个用户组，譬如如果有10台机器，那机器1可以处理10%，如此
• 队列异步：数据获取/计算、生成PDF和Email都分开队列，异步处理，这样每一步的操作不会因为其中一部堵塞后续的操作
• 内存操作：PDF生成无需写入磁盘再作为附件发送出去
• 外部资源：邮件发送可以使用第三方的支持异步的服务，譬如Sendgrid，除了独特的功能之外，我们需要的是无阻塞的异步高性能操作

关于数据获取/计算，如果要做优化，可以在设计上做一些改动，譬如加入每月统计，这样到财年末的时候只需要统计过去12个月的月统计便可。而且这些流水如账本那样，只会append only，不会对现有记录进行改动，所以无需考虑重新统计。

另外，单数据库会是性能（还有安全）瓶颈，完全可以把流水/统计数据放到多节点NoSQL里面，取的时候性能优于关系型数据库。

当然，还有一些更高级、复杂的优化实践，有兴趣的同学们可以根据右边二维码加我的微信。

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。