什么是Pull模型和Push模型？详解两种数据传输模型的优缺点
什么是Pull模型和Push模型？详解两种数据传输模型的优缺点
💡什么是Pull模型？
首先来了解一下什么是Pull模型。Pull的含义是拉取，即消费端主动向中间件进行拉取数据，拉取多少数据完全由消费端的处理能力决定。
举例说明：比如饭堂是服务端，你自己是消费端，当你饿了，你自己主动去饭堂获取食物，但是吃什么菜由你自己决定。
💡Pull模型的优缺点
优点：优点当然是消费端选择自由，想不想消费由消费端自己决定，自由度比较高，吃多少也由你自己决定。
缺点：缺点当然就是实时性啦，也就是你去饭堂吃饭的时候可能菜已经炒出来很久了，你可能不是第一时间点菜吃饭的。
💡什么是Push模型？
Push模型的含义就是推送，即服务端主动将消息推送至消费端。
举例说明：还是利用饭堂的例子，场景是订餐场景，约定好，饭堂叔叔，你的菜炒出来就立马给你进行送餐，保证菜品的新鲜程度，但是菜式和饭量是按照周期由饭堂订，作为用户的你无法进行选择。
💡Push模型的优缺点
优点：优点很明显啦，就是实时性，我可以及时获取到实时的信息。
缺点：缺点就是周一的菜分量太多了，我完全吃不完。。。。也就是消费端的消费速度无法赶上服务端的生产速度，造成消费端压力太大。
💡有没有即实时又有选择的方案？
那就有小伙伴想了，那么我能不能定时去饭堂问呢？那不就可以实时了么？ 这样不就解决了？
试一下，我们在完全不知道厨房叔叔什么时候出菜的情况下，同学们集体根据自己喜欢的菜式，每隔一会一个个去问，叔叔我要的菜好了么？
这场景会让饭堂陷入非常忙碌的状态，并且这些询问在其实对于大多数人来说是重复无意义的询问，因为可能同一时间点已经有其他同学询问了。
并且我应该间隔多少时间询问一次呢？往返饭堂的时间也太久了吧，实在磨人，这些都是不确定性的因素。
pull模型长轮询缺点
所以上述频繁去轮询获取实时信息的方法是不可取的，那么还有其他方案去处理这种情况吗？
这时候我们可以聘请一个监督员帮助我们监察，假如鱼香肉丝菜式炒好了，立马微信通知需要吃鱼香肉丝的同学过来吃饭。这样不仅仅满足了事实性，还增加了自由的选择程度，通知你了，吃不吃或者吃多少都由你自己来决定。
长轮询平衡pull缺点
总结：
Push即服务端主动发送数据给客户端。在服务端收到消息之后立即推送给客户端。
Push模型最大的好处就是实时性。因为服务端可以做到只要有消息就立即推送，所以消息的消费没有“额外”的延迟。
但是Push模式在消息中间件的场景中会面临以下一些问题：
在Broker（服务端）端需要维护Consumer（消费端）的状态，不利于Broker去支持大量的Consumer的场景
Consumer的消费速度是不一致的，由Broker进行推送难以处理不同的Consumer的状况
Broker难以处理Consumer无法消费消息的情况（Broker无法确定Consumer的故障是短暂的还是永久的）
大量的推送消息会加重Consumer的负载或者冲垮Consumer
Pull模式由Consumer主动从Broker获取消息。
这样带来了一些好处：
Broker不再需要维护Consumer的状态（每一次pull都包含了其实偏移量等必要的信息）
状态维护在Consumer，所以Consumer可以很容易的根据自身的负载等状态来决定从Broker获取消息的频率
但是，和Push模式正好相反，Pull就面临了实时性的问题。因为由Consumer主动来Pull消息，所以实时性和Pull的周期相关，这里就产生了“额外”延迟。如果为了降低延迟来提升Pull的执行频率，可能在没有消息的时候产生大量的Pull请求（消息中间件是完全解耦的，Broker和Consumer无法预测下一条消息在什么时候产生）；如果频率低了，那延迟自然就大了。可以采取长轮询的方式进行处理这种情况。
好啦，这就是大概pull/push的一些模型的介绍。