当前位置: 移动技术网 > IT编程>数据库>Mysql > 大数据接口处理时间过长,前端访问超时解决方案

大数据接口处理时间过长,前端访问超时解决方案

2020年08月01日  | 移动技术网IT编程  | 我要评论
引言:最近项目在做一个图片指纹的功能,根据上传图片去筛查出全服务相似图片,筛查部分由算法那边去开发,但是由于数据量巨大,算法给出的接口处理时间可能需要10s(公司网关是6s)。接口的响应时间太长了,网关会报504超时,页面就挂掉了。。。关键点是技术方案要让前端直接跟算法联调(不是应该有个中间服务处理数据吗?)解决方案一:由之前一个算法接口拆分成两个接口,a接口负责启动开始查询,b接口由a接口触发开始查询数据,最后返回状态;前端针对第二个接口实行长轮询具体思路就是:用户触发查询接口a(其实是

引言:

最近项目在做一个图片指纹的功能,根据上传图片去筛查出全服务相似图片,筛查部分由算法那边去开发,但是由于数据量巨大,算法给出的接口处理时间可能需要10s(公司网关是6s)。接口的响应时间太长了,网关会报504超时,页面就挂掉了。。。关键点是技术方案要让前端直接跟算法联调(不是应该有个中间服务处理数据吗?)

解决方案一:

  • 由之前一个算法接口拆分成两个接口,a接口负责启动开始查询,b接口由a接口触发开始查询数据,最后返回状态;
  • 前端针对第二个接口实行长轮询

具体思路就是:

  1. 用户触发查询接口a(其实是后端开始启动一个线程开始查询),接口响应一个状态,返回正在查询
  2. a 接口正常返回查询此时开始调用接口b,b返回3个状态,查询失败,查询成功,正在查询;当status是正在查询时,轮询调用接口b, 直到status变为失败或者成功;
  3. 最后针对于接口需要分页,筛选结果需要表格导出的问题,算法不管,所以这次的讨论结果就用了方案二;

解决方案二:

  • 由之前前端直接对接算法,转换为中间加一层服务;

大概思路:

  • 中间加一层服务之后,前端只需要请求一个接口;前端触发请求接口,接口status返回1,2,3;正在查询,查询成功,查询失败;如果是正在查询就轮询接口(或者提示运营再重新请求一次,后管系统就是这点好处),但是这次查询出来的时间会相对缩短,中间层服务加了一个缓存机制,基本不需要轮询,而且如果是用相同内容去查询,直接从缓存去取就可以了。
  • 筛选结果分页,筛选结果execl导出也很好解决了;绕了一个大圈,哈哈!

最后

方案二的中间层服务,流程图不方便挂出,只是叙述了大概思路,后端的一些专业用语说不太好,可能后端的一眼就看明白了;
针对方案一代码可以参考这里

本文地址:https://blog.csdn.net/ZD717822023/article/details/108193475

如您对本文有疑问或者有任何想说的,请点击进行留言回复,万千网友为您解惑!

相关文章:

验证码:
移动技术网