1、  计算提供两种模式，一种是jar包本地计算、一种是JSF服务。

2、  第一步是引入spark，因与netty、JDQ均有冲突，解决netty冲突后，隔离计算为单独服务。已在线上，因storm也与spark存

在运行时冲突，storm也在用服务。

3、  第二步是召回集扩量，发现当召回集由200扩到500后性能下降过快到70ms，利用多线程多核计算，性能到6ms。已在线上

4、  第三步在此扩量到1000，采用增加线程方式，性能达到25ms左右。已在预发

5、  第四步召回集在扩量，如性能瓶颈是io，则使用jar包本地计算，但与JDQ冲突。需要将线上上报迁移到统一上报服务，服务已有

待联调上线。

6、  第五步在扩召回集，取素材特征与提供接口服务拆分、接口服务通过并发分布式方式进行请求，此时召回集量应为几种方式最大。

需要调整接口服务与素材、特征以及计算服务，通过测试得到IO、线程计算结果合并、多核计算的平衡，需排期配合。

第五步已基本和开源分布式搜索引擎计算方式类似，后续会持续调研新的优化方式，并引入到线上。

可以关注我的公众账户 互联网开发者Club，公众账户分享个性化推荐，搜索，分布式架构，高性能，高可用