调整前:
这里req->redis/db处可以改成M:N模型;
task_pool处主要是计算没有必要替换成M:N模型;
delays mgr处理时,可以通过task_pool处理;
调整后:
第一种:获取doc + handle item + 获取weight + calculate,该方式结构清晰简单,配合M:N模型,问题是,该结构阻塞,pool数目有限,如果,获取doc阻塞,且pool耗尽,没有机会再从队列,其他获取doc请求可能没机会调用,意味着阻塞更久,但pool开到足够大则没问题;但获取weight又要阻塞,一个过程两段阻塞,对pool利用不高;
第二种:task pool + 获取weights + calculate ,配合M:N模型,去掉获取doc部分,缓解上面获取doc对pool利用不高问题;
第三种:如果,获取weight是多处请求,第二种会一个一个阻塞获取,那么就不适用了,需要在目前结构基础,加上weight pool,阻塞获取weight,最后计算;
第四种:task pool 和 calculate pool分别配合M:N模型使用,处理复杂,但pool利用率高,和第二、第三不同的是,获取weight也是异步;该结构就是上面图片的展示;