如何解决并发同时相对耗时的请求
0
悬赏园豆：100
[待解决问题]
1、应用场景
A、物流系统，相当于做物流代理，为客户提供追踪号的label(快递单)
B、物流渠道，主要有USPS、DHL、UPS、FEDEX、TNT等等，国内外物流都有，国外较多
C、请求大致示意过程：
客户 -> 物流系统 -> USPS等物流API
2、高峰期主要集中在上午9点到下午5点之前，目前期望日处理单量为50W左右，后续能方便扩展
3、基本上请求USPS等物流，单个请求耗时一般2-3秒左右（应该是USPS等生成label较耗时）
以下是我预想的大致解决方案：
1、消息队列，客户提交请求后，全部推到队列里，可能存在多个队列，比如按国内还是国外，或者按物流公司区分。
2、用workerman开启多进程订阅消息处理（比如队列中有10000，wokerman开100个进程）
3、处理完后，将结果异步持久化，客户在一段时间后再通过API获取追踪号或label(不一定有追踪号，比如地址错)，这个地方对客户体验怎么样呢，客户都想一次请求就能获取到吧
4、对于第3点，能否考虑客户填写回调地址，服务器作推送呢（目前见到的，似乎都没有这样做的）
对于上述方案，不知可行不可以，里面应该还是要用到负载均衡和代理（国内到国外很慢）吧，以前没有这些方需要经验，还请各位多多指教，想大家帮我理下思路，并给一些建议。
所有回答(3)
0
耗时的问题建议用不同地域的服务器试试, 重点测试是国内外通信慢造成的还是物流渠道方的服务器处理慢造成的慢, 如果是通信慢造成的，可以考虑在国外放服务器(香港是比较中和的点)
0
你“预想的解决方案”明显不符合用户的期望。用户使用你这个东西的场景是，他输入个单号，你马上给他结果。他可以等你出结果，比如等5秒，但必须是实时的，而不是你所说的他先给你的单号，不急着看结果，等你慢慢搞出结果了，再想办法通知他。
这个事耗时主要在你的系统向 “物流渠道”的查询API发送请求它给你结果，所以改善双方服务器的网络通信速度才是关键， “物流渠道”的服务器你管不了，但你们自己的服务器是可以想办法的。
另外，可以考虑对“物流渠道”的查询API结果进行缓存，比如缓存半个小时都是可以接受的。
0
用信号量的WaiteOne（超时时间）,如果到了超时时间来没有结果就回复请重试。
