V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Conte
V2EX  ›  程序员

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

  •  
  •   Conte ·
    ConteMan · 2014-12-03 11:11:39 +08:00 · 3261 次点击
    这是一个创建于 3679 天前的主题,其中的信息可能已经有所发展或是发生改变。
    目前采用并发请求邮局的接口获取包裹跟踪信息,循环请求,直到投妥(包裹到达目的地)。但是由于包裹数量过多,感觉即时性太差,并且并发的请求会出现阻塞,等待的很多。求个思路优化啊,是优化并发请求,提高并发量,还是其他
    12 条回复    2014-12-04 01:24:37 +08:00
    yuankui
        1
    yuankui  
       2014-12-03 13:04:05 +08:00
    多久请求一次啊?
    Conte
        2
    Conte  
    OP
       2014-12-03 13:39:07 +08:00
    @yuankui 因为包裹大多是寄往国外的,一般都要一个月才会投妥,在之前都会需要监测跟踪信息状态变化,理想的是邮局那边跟踪信息一变化我们这边立马就能获取,但是包裹数量巨多,循环完一遍就要很久,所以是按照顺序一遍一遍的请求,轮到了就会请求。
    ryd994
        3
    ryd994  
       2014-12-03 14:22:01 +08:00
    你这没法太频繁的,频繁查询邮局也得挂
    除非你能和邮局合作,在他们的系统里做一个钩子,否则很难有看好解决
    有个可能的优化是根据过往记录,预测两地之间的时间,差不多了再加入轮询
    yuankui
        4
    yuankui  
       2014-12-03 14:30:40 +08:00
    包裹有多少?
    遍历一次要多久?
    Conte
        5
    Conte  
    OP
       2014-12-03 15:32:42 +08:00
    @yuankui 目前发送中的就有44W,其他条件还有100W以上吧 遍历一次多久我不太清楚,但是貌似很慢,即时性不高,业务部门有反应了。
    Conte
        6
    Conte  
    OP
       2014-12-03 15:35:12 +08:00
    @ryd994 他们的接口做的还是比较好,经受得住这样的请求。这个查询的比较多,不只是一个快递,合作对接貌似不好实现,那样当然是最好,有更新“推过来”是十分舒服。我是新手,师傅昨天开会才跟我们说这个问题。
    Sharuru
        7
    Sharuru  
       2014-12-03 15:44:29 +08:00   ❤️ 1
    根据历史物流信息对获取频率做个动态调整?
    比如默认1小时查询一次,在得知包裹被快递员接收后就短时间提高这个包裹的查询频率,直到确认包裹已经分拣发送,然后恢复默认查询频率这样。
    这样做的话,实时性看上去会比较好,毕竟有一些“预测”的成分在里面,但是考虑到Po主这个数据量的话,可能执行起来效率以及负担会不怎么好看。而且预测的过程可能也比较复杂。(比如揽件的时候是接近业务结束,快递员准备回库,还是边揽件边回库这样)
    或者还是默认时间查询,做个按钮让业务员自己去主动获取信息。
    ryd994
        8
    ryd994  
       2014-12-03 15:56:51 +08:00   ❤️ 1
    @Conte 每逢用户需求才查呢?
    如果你有地址信息的话能预测的地方还是很多的,比如根据地址和快递通常的出发时间(一般快递公司都是攒到半夜人少货车才出门的),但是工作量很大啊……
    不一定要合作,说不定邮局已经考虑过了,有相关的
    增加并发数呢?
    aru
        9
    aru  
       2014-12-03 16:52:14 +08:00   ❤️ 1
    多个方法一起来吧
    1. 询问对方系统负载能力,尽量提高并发数
    2. 每次查询后,根据快递类型/目的地/寄送节点等生成下次批量查询的时间。如空运从国内发往美国的路上,批量查询时间是12小时后,海运是7天后,其他都是1小时后。这个规则需要你根据经验慢慢增加
    3. 按需查询,给用户或业务员即时查询接口,并将结果记录到数据库,更新下次批量查询的时间
    suriv520
        10
    suriv520  
       2014-12-03 19:09:34 +08:00   ❤️ 1
    这个想做到靠谱且稳妥,除了把polling模型改为push模型,没有更好的办法。

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

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

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

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

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

    这是学院派的方案。脑洞大开供,纯理论讨论,欢迎拍砖。
    Conte
        11
    Conte  
    OP
       2014-12-04 00:21:14 +08:00
    @Sharuru
    @ryd994
    @aru
    有需求的时候查询这个功能,@suriv520 你说的“当最终用户请求时向后端API发起查询”是有的,就是对于指定包裹,响应速度还是蛮快。好像这个“即时性”的重点是用来自动给业务人员提示、给买家发送到货提示邮件以及比如一个包裹可以选择不同的快递(蛮多),价格变动及运输效率综合择优,数据分析用等。
    大家说动态调整感觉比较不错啊!@suriv520你的这个方案这个是不是就是大数据的事情了~
    看情况目前首先的首选是提高并发量(好像是搞了台转职服务器),后续有进展和大家分享~
    Sharuru
        12
    Sharuru  
       2014-12-04 01:24:37 +08:00 via iPhone
    感觉如果Po主最后选择收集大数据去分析快递运输效率的话,完全可以做成一个独立的、有点新概念的产品了,叫做“帮你选快递”——根据大数据自动分析当前情况下哪家快递速度最好/价格最便宜/最快揽件…什么的——Big news
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2864 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 13:30 · PVG 21:30 · LAX 05:30 · JFK 08:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.