在讲订阅推送之前，我们需要先回顾一下前面提到的物流轨迹查询功能，我们用2种不同的获取物流轨迹的方式做一个对比。有对比才有差距。
先讲一个生活中的小案例，我们都有去商场购买过商品，也遇到过想要买的商品缺货的情况，比如隔壁王阿姨要买的口罩断货了，没有买到，并且这样的口罩只有这家商场卖，王阿姨首先会问商家大概什么时候有货，商家不会给她一个承若，可能会给王阿姨一个大概时间，比如说3天内可能会到货，因为阿姨急着要货，3天内王阿姨多次去商场询问到货情况，去的次数多了，都失去信心了。
好不容易告知已经到货了，走到商场发现一抢而空了。
这样的场景跟快递鸟物流轨迹查询流程非常相似，我们需要主动去请求快递鸟物流轨迹接口，才能知道是否有新的物流轨迹，每个物流公司的轨迹产生有自己的规则，所以每次轨迹查询不一定能查到最新的物流轨迹，要想解决物流及时的问题，我们可能会想到提高查询物流轨迹接口的频率，原来每隔3小时请求一次快递鸟接口，现在改成2小时，好不容易查到物流轨迹了，也及时发送了轨迹信息给客户，结果遭到客户投诉，说我们公司发送垃圾短信，客户2小时前快递就已经签收了，搞的都是事后诸葛亮，后知后觉，也特别尴尬。
于是乎，我们继续修改调用快递鸟接口的频率，这次来狠一点，改成3分钟一次，哇！好开心，轨迹获取非常及时，这个体验真好，当你还没缓过神来，接到快递鸟官方的电话，通知你恶意调用快递鸟接口，需要对你接口限速，其实这还不算什么，当我们业务量大的时候，对服务器有很大压力，大量占用服务器资源。
如果每天有1000个订单需要发货，每天就有1000个运单要查询物流轨迹，一个订单从发货到签收周期是3-7天，我们需要查询所有未签收的运单轨迹，综合统计，一天我们可能需要查询5000千个订单，如果我们对订单时效要求非常高，需要实时了解包裹的签收情况，我们就要反复调用接口，每3分钟调用一次，一个单一天要调用480次，如果时效要求更高，调用更频繁，5000个订单需要调用240万次以上，这样的频繁调用，快递鸟的监控机制直接拦截，属于恶意调用，后果就是快递鸟直接停用对我们的接口查询服务。因此，当业务量大，并且客户对时效要求高的时候，我们需要从新考虑获取物流轨迹的方案。
刚才我们说王阿姨空欢喜一场，没有买到口罩，在他要放弃的时候，商场的一位小姐姐给他出了妙招，告诉他不需要自己跑过来问进货情况，留个电话给商场销售人员，把需求告知销售人员，需要什么样的口罩，买多少个，详细的清单列给工作人员，一旦有货进来，第一时间通知王阿姨过来取货，这样王阿姨就买到了他期盼已久的口罩。王阿姨把需求告知工作人员，这样的方式在快递鸟的业务上称为订阅，客户把所有运单号告诉快递鸟，这就是一次订阅，我们只要通过快递鸟的接口把运单按固定格式推送过去就完成了一次订阅，后续一旦有新的物流轨迹产生，这个时候快递鸟就会把最新的轨迹推送给我们，王阿姨留的电话就是用来通知购物的联系方式，快递鸟的通知方式是通过接口实现的，所以需要我们提供一个可以接收快递鸟最新轨迹信息的接口，只要这个接口是按快递鸟报文接收格式开发的，就能接收到最新的物流轨迹，具体的推送规则，以及接口报文，这里不做讲解，
提供一个快递鸟官网的接口说明地址给大家：http://kdniao.com/api-monitor
通过这样的订阅方式，我们不需要占用服务器太多资源，并且轨迹非常及时，快递鸟官方介绍说，物流公司有新的轨迹产生就会及时推送给我们。
这个时候订阅服务的优势就提现出来了，我们只需要把每天的1000个发货订单推送到快递鸟，让快递鸟去做这个比较繁琐的事情，快递鸟会监控我们推送过去的所有订单，只要没有被签收，快递鸟就会提供推送服务，假设目前有5000个订单还没被签收，快递鸟就会监控这5000个单，其中任何一个单有新的轨迹或者被签收了，快递鸟即时调用我们提供的接口，把轨迹推送到我们的服务器，这样我们就实现了0延迟，真正做到了即时更新物流轨迹，我们利用这个功能可以实现很多产品服务，比如：短信提醒客户订单预计签收时间，统计订单的签收情况，计算订单的发货时效……
原文地址：https://www.cnblogs.com/51api/p/12411335.html