服务扩展后内部结构变化

调整前：

这里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也是异步；该结构就是上面图片的展示；