软件开发中，系统之间如何选择推送和拉取数据？

​

在日常的软件开发过程中，经常会碰到推送和拉取等业务。那么一开始如何选用推送或拉取这两个方案呢？这是由实际业务决定、双方系统的技术实现、双方系统的架构和性能，看日后是否此业务会经常修改等多方面决定的。下面本文就从实际的两个业务情况来讨论。

一、A 系统有一些订单数据，B 系统需要 A 系统的订单数据，并做一些处理。比如 A 系统的订单支付完成之后会转到 B 系统中做销售结算、销售出库等处理。

这种情况我相信大部分人都会决定在 A 系统的订单付完款之后，把订单数据推送到 B 系统中。因为这样选择是合理的。WHY？如果要让 B 系统去轮循地查询 A 系统的订单数据是否被付款，不仅在实时性和准确性上有缺陷，而且在A、B 系统性能上也会有影响，还要处理重复订单问题。所以说由 A 系统推送订单数据到 B 系统是合理的，但这时如果在设计时只是简单地在 A 系统付完款这里做一个推送动作到 B 系统，这其实是不妥的，如果要碰到推送失败，那么如何再推送一次呢？如果把这个推送动作设计成串行的，那会影响到原有流程。所以在这里设计时，要在订单付完款的动作后做推送的动作设计成异步，也可以做成消息机制，由专门的程序去接收消息，并推送到 B 系统，B 系统在接收到订单后要反馈接收成功标志，并且要对重复订单做处理。这才是一个比较完整的处理逻辑。

二、A 系统有一些订单数据，B 系统需要 A 系统的订单数据展示给客户，比如 B 系统要做一个报表展示或实时性不强的操作（比如根据订单生成销售结算的凭证，一天可做一次）。

这种情况就可以设计成 B 系统主动去拉 A 系统的订单数据，然后根据 B 系统的业务维度，分析订单数据，展示订单数据。这样做可减轻 A 系统的压力。但这样做同时也要注意网络带宽、B 系统的数据处理性能的高低与重复数据的处理。对于网络带宽，可以采取分页形式来拉取数据，对于数据处理的性能问题，可以通过管道和队列来一组一组处理订单数据，对于重复数据，可以通过时间戳的形式来解决，时间戳要持久化在 B 系统中。最后也不要忘了在 A 系统中设计视图、中间表甚至报表数据库来作为数据源，最好不要直接操作订单表（读写分离）。

综述，不管是选用哪种形式，都要根据业务的特性来设计，合理地利用接口来实现业务，必要时选用管道、队列、视图、异步、消息队列等方法。

如果你有设计上的问题，欢迎订阅我的公众号：dayupp666 来进行提问，每天还有科技文章喂保您！