1
yuankui 2014-12-03 13:04:05 +08:00
多久请求一次啊?
|
2
Conte OP @yuankui 因为包裹大多是寄往国外的,一般都要一个月才会投妥,在之前都会需要监测跟踪信息状态变化,理想的是邮局那边跟踪信息一变化我们这边立马就能获取,但是包裹数量巨多,循环完一遍就要很久,所以是按照顺序一遍一遍的请求,轮到了就会请求。
|
3
ryd994 2014-12-03 14:22:01 +08:00
你这没法太频繁的,频繁查询邮局也得挂
除非你能和邮局合作,在他们的系统里做一个钩子,否则很难有看好解决 有个可能的优化是根据过往记录,预测两地之间的时间,差不多了再加入轮询 |
4
yuankui 2014-12-03 14:30:40 +08:00
包裹有多少?
遍历一次要多久? |
5
Conte OP @yuankui 目前发送中的就有44W,其他条件还有100W以上吧 遍历一次多久我不太清楚,但是貌似很慢,即时性不高,业务部门有反应了。
|
6
Conte OP @ryd994 他们的接口做的还是比较好,经受得住这样的请求。这个查询的比较多,不只是一个快递,合作对接貌似不好实现,那样当然是最好,有更新“推过来”是十分舒服。我是新手,师傅昨天开会才跟我们说这个问题。
|
7
Sharuru 2014-12-03 15:44:29 +08:00 1
根据历史物流信息对获取频率做个动态调整?
比如默认1小时查询一次,在得知包裹被快递员接收后就短时间提高这个包裹的查询频率,直到确认包裹已经分拣发送,然后恢复默认查询频率这样。 这样做的话,实时性看上去会比较好,毕竟有一些“预测”的成分在里面,但是考虑到Po主这个数据量的话,可能执行起来效率以及负担会不怎么好看。而且预测的过程可能也比较复杂。(比如揽件的时候是接近业务结束,快递员准备回库,还是边揽件边回库这样) 或者还是默认时间查询,做个按钮让业务员自己去主动获取信息。 |
8
ryd994 2014-12-03 15:56:51 +08:00 1
@Conte 每逢用户需求才查呢?
如果你有地址信息的话能预测的地方还是很多的,比如根据地址和快递通常的出发时间(一般快递公司都是攒到半夜人少货车才出门的),但是工作量很大啊…… 不一定要合作,说不定邮局已经考虑过了,有相关的 增加并发数呢? |
9
aru 2014-12-03 16:52:14 +08:00 1
多个方法一起来吧
1. 询问对方系统负载能力,尽量提高并发数 2. 每次查询后,根据快递类型/目的地/寄送节点等生成下次批量查询的时间。如空运从国内发往美国的路上,批量查询时间是12小时后,海运是7天后,其他都是1小时后。这个规则需要你根据经验慢慢增加 3. 按需查询,给用户或业务员即时查询接口,并将结果记录到数据库,更新下次批量查询的时间 |
10
suriv520 2014-12-03 19:09:34 +08:00 1
这个想做到靠谱且稳妥,除了把polling模型改为push模型,没有更好的办法。
但据我推测你们的应用场景,可否尝试考虑“当最终用户请求时向后段API发起查询”?虽然效率慢点,但比长年DDOS空跑要好。 但如果你们确实是需要实时的数据的话,并且也没办法让上级API提供回调的话,或者也没有批量接口的话,只能跟踪每一个订单的源和目的,综合分析历史数据,建立模型。并且实时根据每次获取到的信息,推断并建立当前delivering状态的所有包裹的“批次”数据(这里的批次是指在同一个运输工具里的所有包裹)。 这个批次与分发模型建立起来后,你的系统里应该已经有整个邮局的运输网与运输效率数据了,进阶一点的,可以离散分析周期性的数据,甚至连航班、陆运的班次与起讫时间你都可以了解得一清二楚。 这些建立起来后,你问我怎么获取最新数据?随便把预测的同一个批次的货物里挑选5%或者10%进行API查询,如果有新数据超过一定阈值,说明到货了,再一窝蜂地把关联数据全部调用一次API最终确认。 这是bigdata的基本思维,从混沌(每个包裹)中抽象出上层的关联(批次、运输等),再从上层整体的关联,预测离散的行为,甚至是未来的趋势。 这是学院派的方案。脑洞大开供,纯理论讨论,欢迎拍砖。 |
11
Conte OP |
12
Sharuru 2014-12-04 01:24:37 +08:00 via iPhone
感觉如果Po主最后选择收集大数据去分析快递运输效率的话,完全可以做成一个独立的、有点新概念的产品了,叫做“帮你选快递”——根据大数据自动分析当前情况下哪家快递速度最好/价格最便宜/最快揽件…什么的——Big news
|