系统间数据的 “推送”（Push）和 “拉取”（Pull）

数据的流动是系统设计的一个重要考虑因素，数据的流动发生在客户单与服务端之间。

客户端系统：需要获取数据的一方。

服务端系统：数据的提供方。

客户端从服务端获取数据有两种方式，一种是客户端从服务端拉取数据，另一种是服务端将数据推送给客户端。

这两种方式有各自的特点和适用场景。

Pull（拉取）

1. 实时性
   1. 通常都是定时拉取数据的，这个定时的间隔时间就是实时性的偏差因素之一。
   2. 另外，当服务端数据量大了之后，拉取一次全量也比较耗时，这也是实时性滞后的影响因素之一。
2. 稳定性
   1. 普通的系统一般也不会做限流，只有服务端发现流量太大导致其稳定性出现问题时才可能采取一些限流的措施。
   2. 当然如果服务端做的不好，客户端直接把服务端拉爆了，客户端就需要自己做好失败逻辑的处理了。
3. 复杂度
   1. 拉取这种方式比较简单，有查询接口就可以拉取了。
   2. 普通的系统一般也不会做限流，所以想拉就拉，就是平时开发一个查询接口的成本。
4. 适用场景
   1. 实现性不高的小数据量获取场景。

Push（推送）

1. 实时性
   1. 服务端数据有变化，第一时间通知到客户端，时间间隔基本可以忽略。
   2. 当然，服务端也可以选择不是一有变化就推送数据，而是积攒了一批数据再推，这样实时性也就降低了。
2. 稳定性
   1. 服务端系统的性能开销更加可控些，推送的策略和频率可以由自身控制，甚至根据系统负载动态调整。
   2. 服务端如果是重要的核心系统，通过这种自主可控的推送方式，可以更好的保护自己。
3. 复杂度
   1. 推送可以通过 Webhook 或者 WebSocket 方式实现。
   2. Webhook 需要客户端向服务端注册回调地址，如果回调失败实现需要重试，这个也是需要考虑的一种情况。
   3. WebSocket 则需要服务端提供构建 WebSocket 的功能，客户端需要定时检查维护 WebSocket 是否异常。
4. 适用场景
   1. 数据同步实时性要求高。
   2. 数据量较大时，通增量同步取代全量同步的思路。
   3. 服务端系统的稳定性需要重点保障的场景。

总结：

“拉取” 就是将主动权控制在客户端手里。

“推送” 就是将主动权控制在服务端手里。

通常系统的演化方向是从简单到复杂，所以一般会选择 “先拉后推” 的设计演进。