求个思路，尽可能即时获取包裹的跟踪信息

多久请求一次啊？

@yuankui 因为包裹大多是寄往国外的，一般都要一个月才会投妥，在之前都会需要监测跟踪信息状态变化，理想的是邮局那边跟踪信息一变化我们这边立马就能获取，但是包裹数量巨多，循环完一遍就要很久，所以是按照顺序一遍一遍的请求，轮到了就会请求。

你这没法太频繁的，频繁查询邮局也得挂
除非你能和邮局合作，在他们的系统里做一个钩子，否则很难有看好解决
有个可能的优化是根据过往记录，预测两地之间的时间，差不多了再加入轮询

包裹有多少？
遍历一次要多久？

@yuankui 目前发送中的就有44W，其他条件还有100W以上吧 遍历一次多久我不太清楚，但是貌似很慢，即时性不高，业务部门有反应了。

@ryd994 他们的接口做的还是比较好，经受得住这样的请求。这个查询的比较多，不只是一个快递，合作对接貌似不好实现，那样当然是最好，有更新“推过来”是十分舒服。我是新手，师傅昨天开会才跟我们说这个问题。

根据历史物流信息对获取频率做个动态调整？
比如默认1小时查询一次，在得知包裹被快递员接收后就短时间提高这个包裹的查询频率，直到确认包裹已经分拣发送，然后恢复默认查询频率这样。
这样做的话，实时性看上去会比较好，毕竟有一些“预测”的成分在里面，但是考虑到Po主这个数据量的话，可能执行起来效率以及负担会不怎么好看。而且预测的过程可能也比较复杂。（比如揽件的时候是接近业务结束，快递员准备回库，还是边揽件边回库这样）
或者还是默认时间查询，做个按钮让业务员自己去主动获取信息。

@Conte 每逢用户需求才查呢？
如果你有地址信息的话能预测的地方还是很多的，比如根据地址和快递通常的出发时间（一般快递公司都是攒到半夜人少货车才出门的），但是工作量很大啊……
不一定要合作，说不定邮局已经考虑过了，有相关的
增加并发数呢？

多个方法一起来吧
1. 询问对方系统负载能力，尽量提高并发数
2. 每次查询后，根据快递类型/目的地/寄送节点等生成下次批量查询的时间。如空运从国内发往美国的路上，批量查询时间是12小时后，海运是7天后，其他都是1小时后。这个规则需要你根据经验慢慢增加
3. 按需查询，给用户或业务员即时查询接口，并将结果记录到数据库，更新下次批量查询的时间

这个想做到靠谱且稳妥，除了把polling模型改为push模型，没有更好的办法。

但据我推测你们的应用场景，可否尝试考虑“当最终用户请求时向后段API发起查询”？虽然效率慢点，但比长年DDOS空跑要好。

但如果你们确实是需要实时的数据的话，并且也没办法让上级API提供回调的话，或者也没有批量接口的话，只能跟踪每一个订单的源和目的，综合分析历史数据，建立模型。并且实时根据每次获取到的信息，推断并建立当前delivering状态的所有包裹的“批次”数据（这里的批次是指在同一个运输工具里的所有包裹）。

这个批次与分发模型建立起来后，你的系统里应该已经有整个邮局的运输网与运输效率数据了，进阶一点的，可以离散分析周期性的数据，甚至连航班、陆运的班次与起讫时间你都可以了解得一清二楚。

这些建立起来后，你问我怎么获取最新数据？随便把预测的同一个批次的货物里挑选5%或者10%进行API查询，如果有新数据超过一定阈值，说明到货了,再一窝蜂地把关联数据全部调用一次API最终确认。

这是bigdata的基本思维，从混沌（每个包裹）中抽象出上层的关联（批次、运输等），再从上层整体的关联，预测离散的行为，甚至是未来的趋势。

这是学院派的方案。脑洞大开供，纯理论讨论，欢迎拍砖。

@Sharuru
@ryd994
@aru
有需求的时候查询这个功能，@suriv520 你说的“当最终用户请求时向后端API发起查询”是有的，就是对于指定包裹，响应速度还是蛮快。好像这个“即时性”的重点是用来自动给业务人员提示、给买家发送到货提示邮件以及比如一个包裹可以选择不同的快递（蛮多），价格变动及运输效率综合择优，数据分析用等。
大家说动态调整感觉比较不错啊！@suriv520你的这个方案这个是不是就是大数据的事情了~
看情况目前首先的首选是提高并发量（好像是搞了台转职服务器），后续有进展和大家分享~

感觉如果Po主最后选择收集大数据去分析快递运输效率的话，完全可以做成一个独立的、有点新概念的产品了，叫做“帮你选快递”——根据大数据自动分析当前情况下哪家快递速度最好/价格最便宜/最快揽件…什么的——Big news