一次job的耗时优化经历

一、先聊聊需求

说起这次优化,有点奇葩,从耗时12小时到1分钟,优化经历了三次,和自己纠结了N次,看看结果还算安慰。

1.故事背景

恰逢大促东风,不如顺势来个商品破盘,运营、技术、产品联手一搏提升商品的丰富度。那这次的问题就从这个需求开始了。。。

2.需求描述:快速提升商和品的数量,从现有的商品池中捞出符合规则的数据。

3.功能实现:功能很简单,就是后台通过定时JOB的方式将疑似商品表的数据进行状态更新。over~

二、再聊聊方案

1. 第一种方案(标签:单线程执行、无缓存、有三方依赖)

(1)方案图

  • 疑似商品总数:180w+
  • Page数(50条上限,后面会解释原因):3w+
  • Thread池数:1
  • 是否有缓存:无

一次job的耗时优化经历

(2)执行逻辑

类似的小任务也写过不少,自以为轻车熟路,方案也很顺手,顺手就是一坨代码:
step1:从ODPS表中将疑似商品数据同步到应用的DB表中,做好数据准备
step2:分页获取offer数据,每页必须按照50条数据来执行逻辑。之所以定死这个页数上线,是由于标第三方HSF的接口的限制,用过的童鞋都知道,性能上限每次最多传入50条Id。先忍一忍,继续实现功能。
step3:循环遍历每页,通过第三方接口check是否打上标。然后把已打上标的商品放到一个list集合中。
step4:将list里offer依次循环回写状态
至此coding结束,迫不及待的将任务Run起来。又看看表已凌晨1点多,算了,睡上一觉明天收割数据。早上醒来,蛋疼是事情发生了,才跑了100w的数据,并且一直在报超时。异常显示“HSF TimeOut:OfferQueryServiceException:xxxx”,很显然批量接口不行了,必须优化。

(3)执行结果

本次执行task处理offer数量180w+条,总耗时739分钟,虽然能顺利跑完,但已吐血。简单总结下~

本方案满足了三无条件:

  • 无缓存
  • 无多线程
  • 无延时策略。

本方案暴露的问题:

  • 第三方的接口依赖成为性能瓶颈,多频次的循环调用会造成应用的强依赖和性能瓶颈
  • 本次处理的数据量还是比较大,单Thread方案肯定不合适,
  • ODPS表同步DB每周才执行一次,数据的实时性比较弱,完全可以缓存调用offerQueryService的接口,提升性能
  • hsf超时严重,需要增加sleep降低调用频次的时间间隔

2.第二种方案(标签:多线程执行、有缓存、有三方依赖)

(1)方案图

  • 疑似offer总数:180w+
  • Page数(50条上限,后面会解释原因):3w+
  • Thread池数:6
  • 是否有缓存:增加offer接口调用1小时的缓存
  • 并发策略:根据线程池数量动态分配数数据的起止页,并发执行

一次job的耗时优化经历

(2)执行逻辑

按照方案一的暴漏问题,逐一优化:

  • step1:增加线程和数据页数的动态分配策略
         一次job的耗时优化经历
  • step2:多个线程并发执行,并增加sleep降低访问依赖频率
    一次job的耗时优化经历
  • step3:增减读取offerQueryService的tair存储。

(3)执行结果

本次执行task处理offer数量180w+条,总耗时127分钟,时间提升82%,期间无任何异常抛出,终于可以静静的吃瓜了。但又想了想,是不是还有更好的思路可以解决这个问题呢:

  • 能不能将时间控制在分钟级别?
  • 能不能不依赖第三方接口?
  • 能不能不用缓存降低数据丢失或未被命中的概率?

本方案也暴露一些问题:

  • 始终在围绕解决方案一暴漏问题在优化,思路没有打开
  • 最大的瓶颈还是依赖第三方接口,必须降级去掉
  • tair已经做到常态化演练,申请空间又是MDB模式,数据丢失成为一种风险。

3.第三种方案(标签:嵌套SQL、无三方依赖、批量优化)

(1)方案图

  • 疑似offer总数:180w+
  • Page分页:不需要
  • Thread池数:不要要
  • 是否有缓存:不需要

一次job的耗时优化经历

(2)执行逻辑
从头开始理解需求,无非就是想把疑似商品找出来,然后回写状态。能不能找到替代调用三方接口的方案来验证结果。脑暴一番,果然有。。。

  • step1:替换掉接口依赖,使用odps中的离线xxx表中的数据,然后同步到DB中。这不看起来比较麻烦,但一劳永逸,为后续的性能优化起到关键行作用,直接将时间降级至分钟级。
  • step2:求交集,将DB表1和DB表2联合查询,结果即为已经完成升级的offer列表
  • step3:优化update方法为批量更新,至此over

(3)执行结果

本次执行task处理offer数量180w+条,总耗时<<1分钟,时间提升100%,期间无任何异常抛出。

三、小结

回头想想这次优化的经历,总结有三点:

  • 来一个需求先不要着急码代码,分析好场景和数据基础,然后选择最优的技术方案。避免后续的返工
  • 思路方向很重要,往往很复杂的方案背后,换种思路会更爽
  • 事情搞完后和自己纠结下,往往会有新的发现
上一篇:Android API 中文(13) —— ToggleButton


下一篇:MongoDB学习笔记(二)--Capped集合 && GridFS存储文件