1.后端接口优化相关:
这里记录一下遇到的一个很坑爹的问题,
项目在正式环境中出现了部分接口访问时快时慢的问题,这些接口在数据库访问和代码的优化都已经做到最优,但是仍然出现了有时候毫秒级返回有时候需要十多秒甚至二三十秒返回的问题。最终在nginx日志那里发现请求的到达时间有时候会变得异常的缓慢。起先我是十分怀疑是正式环境的网络有问题,像是那种不明波动,因为之前也确实出现过问题(但是修复了),不过如果是网络问题的话,为什么其它服务接口又能很稳定的调用呢。几经排查发现,接口慢在页面列表的项目需要加载图片的时候才会出现,场景就是每个列表的图片都是单独加载的,而且是加载的用户上传的原图,没有做任何的缩小,转码处理。正常的处理一般的都是静态化存放在ng或者特定位置,不过这次问题主要原因在minio的文件获取,在谷歌上也看到了类似的问题描述,说是minio对于多个小文件的读写会出现效率低下的问题,现场的情况是在手工上传了新文件后,文件获取速度会正常一段时间,而后又变得很慢,这就比较明显是minio的内部机制有不完善的地方了。后来通过升级minio发现提示说linux系统内核版本低,可能会影响性能,另外因为之前磁盘的空间不足,将minio的数据目录存改为了一个新的2.2T的挂载目录,然而启动命令并没有修改,所以这也有可能对minio的文件访问产生影响,所以这里还在做进一步尝试。(目前就是锁定这两个因素,如果还是效率低下,那么说明minio最新版本可能还是没有解决这个同时多个小文件读写的问题,结果会后续更新。。。)
另一个问题是,用户反应邮件列表查询有时快时慢的问题,这里邮件的总量大概在百万级,而邮件的解析工作是一直在进行的,只要平台有新的邮件解析任务插入了任务表中,应用这边就会不断的往邮件表里插入新的数据。这样必然导致索引也在逐渐变大,索引的维护成本也跟着上升,随之而来的问题是,数据的插入和更新都会变得效率十分低下。不过鉴于本系统主要的工作是查询和插入,对于插入操作来说,因为数据量本身巨大,并且用户也不需要查看实时插入的数据,所以这里将解析的操作改为只在用户的非工作时间进行。(进阶,当数据量大到一定程度,索引可能也不合适了,但是oracle对于千万左右的数据还是有比较好的支持,所以暂时咩有分表)