qs收集结果

前一段处理qs网络堵塞的问题，进一步将lq和qs之间的通信做了一些梳理，记录一下。

我们知道，lq是一遍查找，一遍向qs发送请求的，每遍历一定数量的doc后（比如说60w，具体和工作场景有关），就向qs发送一定数量的结果。qs将这些答复汇总后记录，当达到一定的条件之后，就发送cancel信号，lq停止查找。

以前以为lq发送一定的结果之后，就停止查找，qs也是偶尔才会发送cancel信号。这样的好处是lq运行效率高，因为越到后面，doc的质量越差。早早结束查找，可以空出资源处理后面的请求。这次才发现，只要还有lq没有发送结果后者某一台lq的结果没有达到要求，qs就会一直不会发送cancel信号，其他的lq也会一直进行查找，直到qs觉得结果已经做够好或者已经超时。这样的模式保证了所有的lq都有机会发送结果，不会因为某一台或者几台性能太好，导致别的lq没机会进行查找。这种模式虽然对资源有些浪费，但是保证了召回率。

另外，qs在返回cache的结果中，标识了哪些lq没有发送结果，后面cache在更新的时候，能够根据标志位进行补查找。