本文主要是介绍接口数据推拉的东东20190424，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
接口数据推拉的东东
1,什么是接口推送/拉取数据
2,如何选择推送/拉取数据
3,推送/拉取数据优缺点
4,总结
1,什么是接口推送/拉取数据
推送VS拉取
推送与拉取是两种不同系统间的通信,这两种方式解释了数据生产者与数据消费者是如何进行数据交互的.
推送
推送是数据生产者把生产的存储的数据传输到数据消费者里(消费者提供接收的接口),数据消费者是不知何时能接收到何时的数据,消费者接收到数据的时点是由数据生产者决定的.(业务时点可触发,可定时)
拉取
拉取是数据消费者从数据生产者get数据源,数据生产者只需要提供数据源(提供数据源的接口),不用关心,也不知道数据消费者何时获取该数据.数据消费者决定获取数据的时点(定时)
| 接口类型 | 数据生产者 | 数据消费者 |
| 拉取 | 被动的:当被请求时提供数据源。 | 主动的:决定何时请求去获取数据。 |
| 推送 | 主动的:按自己的时点(业务时点/定时时点)传输数据。 | 被动的:对收到的数据做出反应。 |
2,如何选择推送/拉取数据
推送
若果数据实时性要求比较强,可采用数据生产端推送.
推送案例
订单系统的订单数据出库后实时转到售后系统生成派工单,工程师派工处理等.(由订单系统推送到售后系统)
推送案例分析
一些企业对派工效率要求比较高,提高服务效率,提升品牌的服务口碑.若果让售后系统定时主动获取订单系统出库未派工数据,难以保证出库数据的实时性和准确性,不停的轮询抓取数据,也会导致系统有不必要的系统性能消耗.
拉取
若果数据实时性不强,宜采用数据消费端拉取数据.
拉取案例
订单系统的发票数据开票回写实时性要求不强,只需要开票中的发票数据定时取对应的数据进行开票状态更新等相关操作.
拉取案例分析
不知道怎么分析了.............
知道的帮忙补充下,谢谢!
3,推送/拉取数据优缺点
| 接口类型 | 优点 | 缺点 |
| 拉取 | 1,减轻数据生产者端的系统压力 | 1,容易发生漏拉取的数据,还难以发现具体明细数据 |
| 2,增加空轮询,增加额外性能开销 | ||
| 推送 | 1,实时性高,数据消费者端能第一时间接收到最新数据 | 1,不能确保每次推送都成功被接收,需有未确认成功重推机制(数据生产者端复杂化) |
| 2,数据消费者端每次被动接收非空数据,避免空轮询的额外开销,减少服务压力 | 2,缺乏数据的多样性,可能有比较大的数据冗余存在.(数据消费者端无法根据自身需要固定要自身业务相关的数据字段) | |
| 3,数据消费者端接口简单化 |
|
4,总结
个人观点
个人认为在实际工作中,同一个接口应采用混合方式.混合式是同一接口指既有推送也有拉取!以推送为主,以拉取为辅!拉取数据为辅是指手动触发拉取数据!
为什么个人观点采用混合呢
当开发时间充足,采取推送为主,达到数据时效性高,系统性能额外开销减少!当系统推送部分数据异常导致局部推送漏或者,接收数据方异常多次没成功接收数据,需要人为触发拉取数据以解决该异常问题!
客观观点
考虑到开发周期问题,根据业务需求,系统架构等方面考虑,主要按照时间,效率,工作量,是否需求数据实时性特别高等再选择接口采取哪种方式!不管是选用哪种形式，都要根据业务的特性来设计，合理地利用接口来实现业务，必要时选用管道、队列、视图、异步、消息队列等方法。
感谢大家观看！
如有错误请指出互相交流,让小弟也学习学习,谢谢!
这篇关于接口数据推拉的东东20190424的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
