qs collection result

The previous paragraph dealt with the problem of qs network congestion, and further sorted out the communication between lq and qs and recorded it.

We know that lq is a search and sends a request to qs. After traversing a certain number of docs (for example, 60w, which is related to the work scenario), a certain number of results are sent to qs. qs summarizes these replies and records them. When certain conditions are met, it sends a cancel signal, and lq stops searching.

I used to think that after lq sent a certain result, it stopped searching, and qs also occasionally sent a cancel signal. The advantage of this is that lq runs efficiently, because the further back, the worse the quality of doc. Ending the search early can free up resources to handle subsequent requests. Only this time I found that as long as there are still lqs that have not sent results, the results of one of the latter lqs do not meet the requirements, qs will never send cancel signals, and other lqs will continue to search until qs feels that the results have been done enough. OK or timed out. This mode ensures that all lqs have the opportunity to send results, and other lqs will not have a chance to search because one or several performance is too good. Although this mode is a bit wasteful of resources, it guarantees the recall rate.

In addition, qs identifies which lqs did not send results in the results returned to the cache. When the cache is updated later, it can perform supplementary searches according to the flag bits.