pull
作为一个messaging system，Kafka遵循了传统的方式，选择由producer向broker push消息并由consumer从broker pull消息。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume,采用非常不同的push模式。事实上，push模式和pull模式各有优劣。
push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。
一、生产者到broker
生产者push消息到broker，采用推模式，生产者将消息推送给消费者。
push模式的目标是尽可能以最快速度传递消息。生产者采用pull的话，不是很适合有成千上万的生产者的情况，假如生产者写入日志，broker从日志中pull，当生产者非常多，成千上万的磁盘系统并不是时时可靠的，那样大大增加了系统的复杂性。
二、broker到消费者
broker到消费者采用pull，拉模式。消费者主动到服务器拉取消息。
push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成消费者来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。
另外它有助于消费者合理的批处理消息。不同的消费者消费速率，外部硬件环境都不一样，交由消费者自己决定以何种频率拉取消息更合适。
基于pull模式不足之处在于，如果broker没有数据，消费者会轮询，忙等待数据直到数据到达，为了避免这种情况，我们允许消费者在pull请求时候使用“long poll”进行阻塞，直到数据到达 。
- 消息分发
Producer客户端负责消息的分发
kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含”集群中存活的servers列表”/”partitions leader列表”等信息；
当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
消息由producer直接通过socket发送到broker，中间不会经过任何”路由层”，事实上，消息被路由到哪个partition上由producer客户端决定；比如可以采用”random”“key-hash”“轮询”等,如果一个topic中有多个partitions，那么在producer端实现”消息均衡分发”是必要的。
在producer端的配置文件中,开发者可以指定partition路由的方式。
Producer消息发送的应答机制
设置发送数据是否需要服务端的反馈,有三个值0,1,-1
l 0: producer不会等待broker发送ack
l 1: 当leader接收到消息之后发送ack
l -1: 当所有的follower都同步消息成功后发送ack
request.required.acks=0
- 消费者push、pull机制
作为一个message system，kafka遵循了传统的方式，选择由kafka的producer向broker push信息，而consumer从broker pull信息。
consumer获取消息，可以使用两种方式：push或pull模式。下面我们简单介绍一下这两种区别：
push模式
常见的push模式如storm的消息处理，由spout负责消息的推送。该模式下需要一个中心节点，负责消息的分配情况（哪段消息分配给consumer1，哪段消息分配给consumer2），同时还要监听consumer的ack消息用于判断消息是否处理成功，如果在timeout时间内为收到响应可以认为该consumer挂掉，需要重新分配sonsumer上失败的消息。这种模式有个问题，不太容易实现我们想要的消息回放功能，因为理想情况下由consumer决定我到底要消费什么，而这种模式完全由master决定。
pull模式
如上图模式，该模式为pull模式，由consumer决定消息的消费情况，这种模式有一个好处是我们不需要返回ack消息，因为当consumer申请消费下一批消息时就可以认为上一批消息已经处理完毕，也不需要处理超时的问题，consumer可以根据自己的消费能力来消费消息。但这个还有一个问题，如何保证处理的消息的不会重复呢，kafka具体做法就是增加队列的并发度（partition），可以一个partition对准一个consumer。
综上，kafka的consumer之所以没有采用push模式，是因为push模式很难适应消费者速率不同的消费者而且很难实现消息的回放功能，因为消息发送速率是由broker决定的。push模式的目标就是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞，而pull模式则可以根据consumer的消费能力以适当的速率消费message。
pull与push的区别
pull技术：
客户机向服务器请求信息；
kafka中，consuemr根据自己的消费能力以适当的速率消费信息；
push技术：
服务器主动将信息发往客户端的技术；
push模式的目标就是尽可能以最快的速率传递消息。
场景 1：Producer 的速率大于 Consumer 的速率
对于 Producer 速率大于 Consumer 速率的情况，有两种可能性需要讨论:
第一种是Producer 本身的效率就要比 Consumer 高（比如说，Consumer 端处理消息的业务逻辑可能很复杂，或者涉及到磁盘、网络等 I/O操作）；
另一种则是 Consumer 出现故障，导致短时间内无法消费或消费不畅。
Push方式由于无法得知当前 Consumer 的状态（），所以只要有数据产生，便会不断地进行推送，在以上两种情况下时，可能会导致 Consumer 的负载进一步加重，甚至是崩溃（比如生产者是 flume 疯狂抓日志，消费者是 HDFS+hadoop，处理效率跟不上）。除非Consumer 有合适的反馈机制能够让服务端知道自己的状况。（也可以 通过消费端限流方案，比如RabbitMQ消费者设置Qos，服务端Borker就会限制对消费端的发送流程，但是这个流量设置就需要衡量，不能太大也不能太小）
而采取 Pull 的方式问题就简单了许多，由于 Consumer 是主动到服务端拉取数据，此时只需要降低自己访问频率就好了。举例：如前端是 flume 等日志收集业务，不断往 CMQ 生产消息，CMQ 往后端投递，后端业务如数据分析等业务，效率可能低于生产者。
场景 2：强调消息的实时性
采用 Push 的方式时，一旦消息到达，服务端即可马上将其推送给服务端，这种方式的实时性显然是非常好的；
而采用 Pull 方式时，为了不给服务端造成压力（尤其是当数据量不足时，不停的轮询显得毫无意义），需要控制好自己轮询的间隔时间，但这必然会给实时性带来一定的影响。（Pull不会频繁拉取，设置一定间隔）。
场景 3：Pull 的长轮询
Pull 模式有什么问题呢？由于主动权在消费方，消费方无法准确地决定何时去拉取最新的消息。如果一次 Pull 取到消息了还可以继续去 Pull，如果没有 Pull 取到消息则需要等待一段时间再重新 Pull。
但等待时间就很难判定了。你可能会说，我可以有xx 动态拉取时间调整算法，但问题的本质在于，有没有消息到来这件事情决定权不在消费方。也许 1 分钟内连续来了 1000 条消息，然后半个小时没有新消息产生，可能你的算法算出下次最有可能到来的时间点是31分钟之后，或者 60 分钟之后，结果下条消息 10 分钟后到了，是不是很让人沮丧？
当然也不是说延迟就没有解决方案了，业界较成熟的做法是从短时间开始（不会对 CMQ broker 有太大负担），然后指数级增长等待。比如开始等 5ms，然后 10ms，然后 20ms，然后 40ms……直到有消息到来，然后再回到 5ms。即使这样，依然存在延迟问题：假设 40ms 到 80ms 之间的 50ms 消息到来，消息就延迟了 30ms，而且对于半个小时来一次的消息，这些开销就是白白浪费的。
总之就是消费端长时间没有消息消费的话，消费端轮训时间间隔如果太长，可能在轮训间隔中让部分消息延时消费，如果轮训时间太短，则频繁的请求在消耗服务端Broker，broker要应答消费端的请求（线程开销等）而造成服务端Broker的负担。
在腾讯云的 CMQ 里，有一种优化的做法-长轮询，来平衡 Pull/Push 模型各自的缺点。
基本方式是：消费者如果尝试拉取失败，不是直接 return，而是把连接挂在那里 wait，服务端如果有新的消息到来，把连接拉起，返回最新消息。
场景 4：部分或全部 Consumer 不在线
在消息系统中，Producer 和 Consumer 是完全解耦的，Producer 发送消息时，并不要求Consumer 一定要在线，对于 Consumer 也是同样的道理，这也是消息通信区别于 RPC 通信的主要特点；但是对于 Consumer不在线的情况，却有很多值得讨论的场景。
首先，在 Consumer 偶然宕机或下线的情况下，Producer 的生产是可以不受影响的，Consumer 上线后，可以继续之前的消费，此时消息数据不会丢失；但是如果 Consumer 长期宕机或是由于机器故障无法再次启动，就会出现问题，即服务端需不需要为 Consumer 保留数据，以及保留多久的数据等等。(消费端宕机，服务端Broker数据堆积)
采用 Push 方式时，因为无法预知 Consumer 的宕机或下线是短暂的还是持久的，如果一直为该 Consumer 保留自宕机开始的所有历史消息，那么即便其他所有的 Consumer 都已经消费完成，数据也无法清理掉，随着时间的积累，队列的长度会越来越大，此时无论消息是暂存于内存还是持久化到磁盘上（采用 Push 模型的系统，一般都是将消息队列维护于内存中，以保证推送的性能和实时性，这一点会在后边详细讨论），都将对 MQ 服务端造成巨大压力，甚至可能影响到其他 Consumer 的正常消费，尤其当消息的生产速率非常快时更是如此；但是如果不保留数据，那么等该 Consumer 再次起来时，则要面对丢失数据的问题。
折中的方案是：MQ 给数据设定一个超时时间，当 Consumer 宕机时间超过这个阈值时，则清理数据；但这个时间阈值也并太容易确定。
在采用 Pull 模型时，情况会有所改善；服务端不再关心 Consumer 的状态，而是采取“你来了我才服务”的方式，Consumer 是否能够及时消费数据，服务端不会做任何保证（也有超时清理时间）。
Push VS Pull
- Push
Push即服务端主动发送数据给客户端。在服务端收到消息之后立即推送给客户端。
Push模型最大的好处就是实时性。因为服务端可以做到只要有消息就立即推送，所以消息的消费没有“额外”的延迟。
但是Push模式在消息中间件的场景中会面临以下一些问题：
在Broker端需要维护Consumer的状态，不利于Broker去支持大量的Consumer的场景
Consumer的消费速度是不一致的，由Broker进行推送难以处理不同的Consumer的状况
Broker难以处理Consumer无法消费消息的情况（Broker无法确定Consumer的故障是短暂的还是永久的）
大量的推送消息会加重Consumer的负载或者冲垮Consumer
Pull模式可以很好的应对以上的这些场景。
2.Pull
Pull模式由Consumer主动从Broker获取消息。
这样带来了一些好处：
Broker不再需要维护Consumer的状态（每一次pull都包含了其实偏移量等必要的信息）
状态维护在Consumer，所以Consumer可以很容易的根据自身的负载等状态来决定从Broker获取消息的频率
Pull模式还有一个好处是可以聚合消息。
因为Broker无法预测写一条消息产生的时间，所以在收到消息之后只能立即推送给Consumer，所以无法对消息聚合后再推送给Consumer。 而Pull模式由Consumer主动来获取消息，每一次Pull时都尽可能多的获取已近在Broker上的消息。
但是，和Push模式正好相反，Pull就面临了实时性的问题。
因为由Consumer主动来Pull消息，所以实时性和Pull的周期相关，这里就产生了“额外”延迟。如果为了降低延迟来提升Pull的执行频率，可能在没有消息的时候产生大量的Pull请求（消息中间件是完全解耦的，Broker和Consumer无法预测下一条消息在什么时候产生）；如果频率低了，那延迟自然就大了。
另外，Pull模式状态维护在Consumer，所以多个Consumer之间需要相互协调，这里就需要引入ZK或者自己实现NameServer之类的服务来完成Consumer之间的协调。
有没有一种方式，能结合Push和Pull的优势，同时变各自的缺陷呢？答案是肯定的。
Long-Polling
使用long-polling模式，Consumer主动发起请求到Broker，正常情况下Broker响应消息给Consumer；在没有消息或者其他一些特殊场景下，可以将请求阻塞在服务端延迟返回。
long-polling不是一种Push模式，而是Pull的一个变种。
那么：
在Broker一直有可读消息的情况下，long-polling就等价于执行间隔为0的pull模式（每次收到Pull结果就发起下一次Pull请求）。
在Broker没有可读消息的情况下，请求阻塞在了Broker，在产生下一条消息或者请求“超时之前”响应请求给Consumer。
以上两点避免了多余的Pull请求，同时也解决Pull请求的执行频率导致的“额外”的延迟。
注意上面有一个概念：“超时之前”。每一个请求都有超时时间，Pull请求也是。“超时之前”的含义是在Consumer的“Pull”请求超时之前。
基于long-polling的模型，Broker需要保证在请求超时之前返回一个结果给Consumer，无论这个结果是读取到了消息或者没有可读消息。
因为Consumer和Broker之间的时间是有偏差的，且请求从Consumer发送到Broker也是需要时间的，所以如果一个请求的超时时间是5秒，而这个请求在Broker端阻塞了5秒才返回，那么Consumer在收到Broker响应之前就会判定请求超时。所以Broker需要保证在Consumer判定请求超时之前返回一个结果。
通常的做法时在Broker端可以阻塞请求的时间总是小于long-polling请求的超时时间。比如long-polling请求的超时时间为30秒，那么Broker在收到请求后最迟在25s之后一定会返回一个结果。中间5s的差值来应对Broker和Consumer的始终存在偏差和网络存在延迟的情况。 （可见Long-Polling模式的前提是Broker和Consumer之间的时间偏差没有“很大”）
Long-Polling还存在什么问题吗，还能改进吗？
Dynamic Push/Pull
“在Broker一直有可读消息的情况下，long-polling就等价于执行间隔为0的pull模式（每次收到Pull结果就发起下一次Pull请求）。”
这是上面long-polling在服务端一直有可消费消息的处理情况。在这个情况下，一条消息如果在long-polling请求返回时到达服务端，那么它被Consumer消费到的延迟是：
假设Broker和Consumer之间的一次网络开销时间为R毫秒，
那么这条消息需要经历3R才能到达Consumer
第一个R：消息已经到达Broker，但是long-polling请求已经读完数据准备返回Consumer，从Broker到Consumer消耗了R
第二个R：Consumer收到了Broker的响应，发起下一次long-polling，这个请求到达Broker需要一个R
的时间
第三个R：Broker收到请求读取了这条数据，那么返回到Consumer需要一个R的时间
所以总共需要3R（不考虑读取的开销，只考虑网络开销）
另外，在这种情况下Broker和Consumer之间一直在进行请求和响应（long-polling变成了间隔为0的pull）。
考虑这样一种方式，它有long-polling的优势，同时能减少在有消息可读的情况下由Broker主动push消息给Consumer，减少不必要的请求。
消息中间件的Consumer实现
在消息中间件的Consumer中会有一个Buffer来缓存从Broker获取的消息，而用户的消费线程从这个Buffer中获取消费来消息，获取消息的线程和消费线程通过这个Buffer进行数据传递。
pull线程从服务端获取数据，然后写入到Buffer
consume线程从Buffer获取消息进行消费
有这个Buffer的存在，是否可以在long-polling请求时将Buffer剩余空间告知给Broker，由Broker负责推送数据。此时Broker知道最多可以推送多少条数据，那么就可以控制推送行为，不至于冲垮Consumer。
上面这幅图是akka的Dynamic Push/Pull示意图，思路就是每次请求会带上本地当前可以接收的数据的容量，这样在一段时间内可以由Server端主动推送消息给请求方，避免过多的请求。
akka的Dynamic Push/Pull模型非常适合应用到Consumer获取消息的场景。
Broker端对Dynamic Push/Pull的处理流程大致如下：
收到long-polling请求
while(有数据可以消费&请求没超时&Buffer还有容量) {
读取一批消息
Push到Consumer
Buffer-PushedAmount 即减少Buffer容量
}
response long-polling请求
结束（等待下一个long-polling再次开始这个流程）
Consumer端对Dynamic Push/Pull的处理流程大致如下：
收到Broker的响应：
if (long-polling的response) {
将获取的消息写入Buffer
获取Buffer的剩余容量和其他状态
发起新的long-polling请求
} else {
// Dynamic Push/Pull的推送结果
将获取的消息写入到Buffer（不发起新的请求）
}
举个例子：
Consumer发起请求时Buffer剩余容量为100，Broker每次最多返回32条消息，那么Consumer的这次long-polling请求Broker将在执行3次push(共push96条消息)之后返回response给Consumer（response包含4条消息）。
如果采用long-polling模型，Consumer每发送一次请求Broker执行一次响应，这个例子需要进行4次long-polling交互（共4个request和4个response，8次网络操作；Dynamic Push/Pull中是1个request，三次push和一个response，共5次网络操作）。
总结：
Dynamic Push/Pull的模型利用了Consumer本地Buffer的容量作为一次long-polling最多可以返回的数据量，相对于long-polling模型减少了Consumer发起请求的次数，同时减少了不必要的延迟（连续的Push之间没有延迟，一批消息到Consumer的延迟就是一个网络开销；long-polling最大会是3个网络开销）。
Dynamic Push/Pull还有一些需要考虑的问题，比如连续推送的顺序性保证，如果丢包了怎么处理之类的问题，有兴趣可以自己考虑一下（也可以私下交流）。
结语
本篇内容比较了Push、Poll、Long-Polling、Dynamic Push/Pull模型。
Push模型实时性好，但是因为状态维护等问题，难以应用到消息中间件的实践中。
Pull模式实现起来会相对简单一些，但是实时性取决于轮训的频率，在对实时性要求高的场景不适合使用。
Long-Polling结合了Push和Pull各自的优势，在Pull的基础上保证了实时性，实现也不会非常复杂，是比较常用的一种实现方案。
Dynamic Push/Pull在Long-Polling的基础上，进一步优化，减少更多不必要的请求。但是先对实现起来会复杂一些，需要处理更多的异常情况。
参考内容：Google->Reactive Stream Processing with Akka StreamsPush VS Pull
- Push
Push即服务端主动发送数据给客户端。在服务端收到消息之后立即推送给客户端。
Push模型最大的好处就是实时性。因为服务端可以做到只要有消息就立即推送，所以消息的消费没有“额外”的延迟。
但是Push模式在消息中间件的场景中会面临以下一些问题：
在Broker端需要维护Consumer的状态，不利于Broker去支持大量的Consumer的场景
Consumer的消费速度是不一致的，由Broker进行推送难以处理不同的Consumer的状况
Broker难以处理Consumer无法消费消息的情况（Broker无法确定Consumer的故障是短暂的还是永久的）
大量的推送消息会加重Consumer的负载或者冲垮Consumer
Pull模式可以很好的应对以上的这些场景。
2.Pull
Pull模式由Consumer主动从Broker获取消息。
这样带来了一些好处：
Broker不再需要维护Consumer的状态（每一次pull都包含了其实偏移量等必要的信息）
状态维护在Consumer，所以Consumer可以很容易的根据自身的负载等状态来决定从Broker获取消息的频率
Pull模式还有一个好处是可以聚合消息。
因为Broker无法预测写一条消息产生的时间，所以在收到消息之后只能立即推送给Consumer，所以无法对消息聚合后再推送给Consumer。 而Pull模式由Consumer主动来获取消息，每一次Pull时都尽可能多的获取已近在Broker上的消息。
但是，和Push模式正好相反，Pull就面临了实时性的问题。
因为由Consumer主动来Pull消息，所以实时性和Pull的周期相关，这里就产生了“额外”延迟。如果为了降低延迟来提升Pull的执行频率，可能在没有消息的时候产生大量的Pull请求（消息中间件是完全解耦的，Broker和Consumer无法预测下一条消息在什么时候产生）；如果频率低了，那延迟自然就大了。
另外，Pull模式状态维护在Consumer，所以多个Consumer之间需要相互协调，这里就需要引入ZK或者自己实现NameServer之类的服务来完成Consumer之间的协调。
有没有一种方式，能结合Push和Pull的优势，同时变各自的缺陷呢？答案是肯定的。
Long-Polling
使用long-polling模式，Consumer主动发起请求到Broker，正常情况下Broker响应消息给Consumer；在没有消息或者其他一些特殊场景下，可以将请求阻塞在服务端延迟返回。
long-polling不是一种Push模式，而是Pull的一个变种。
那么：
在Broker一直有可读消息的情况下，long-polling就等价于执行间隔为0的pull模式（每次收到Pull结果就发起下一次Pull请求）。
在Broker没有可读消息的情况下，请求阻塞在了Broker，在产生下一条消息或者请求“超时之前”响应请求给Consumer。
以上两点避免了多余的Pull请求，同时也解决Pull请求的执行频率导致的“额外”的延迟。
注意上面有一个概念：“超时之前”。每一个请求都有超时时间，Pull请求也是。“超时之前”的含义是在Consumer的“Pull”请求超时之前。
基于long-polling的模型，Broker需要保证在请求超时之前返回一个结果给Consumer，无论这个结果是读取到了消息或者没有可读消息。
因为Consumer和Broker之间的时间是有偏差的，且请求从Consumer发送到Broker也是需要时间的，所以如果一个请求的超时时间是5秒，而这个请求在Broker端阻塞了5秒才返回，那么Consumer在收到Broker响应之前就会判定请求超时。所以Broker需要保证在Consumer判定请求超时之前返回一个结果。
通常的做法时在Broker端可以阻塞请求的时间总是小于long-polling请求的超时时间。比如long-polling请求的超时时间为30秒，那么Broker在收到请求后最迟在25s之后一定会返回一个结果。中间5s的差值来应对Broker和Consumer的始终存在偏差和网络存在延迟的情况。 （可见Long-Polling模式的前提是Broker和Consumer之间的时间偏差没有“很大”）
Long-Polling还存在什么问题吗，还能改进吗？
Dynamic Push/Pull
“在Broker一直有可读消息的情况下，long-polling就等价于执行间隔为0的pull模式（每次收到Pull结果就发起下一次Pull请求）。”
这是上面long-polling在服务端一直有可消费消息的处理情况。在这个情况下，一条消息如果在long-polling请求返回时到达服务端，那么它被Consumer消费到的延迟是：
假设Broker和Consumer之间的一次网络开销时间为R毫秒，
那么这条消息需要经历3R才能到达Consumer
第一个R：消息已经到达Broker，但是long-polling请求已经读完数据准备返回Consumer，从Broker到Consumer消耗了R
第二个R：Consumer收到了Broker的响应，发起下一次long-polling，这个请求到达Broker需要一个R
的时间
第三个R：Broker收到请求读取了这条数据，那么返回到Consumer需要一个R的时间
所以总共需要3R（不考虑读取的开销，只考虑网络开销）
另外，在这种情况下Broker和Consumer之间一直在进行请求和响应（long-polling变成了间隔为0的pull）。
考虑这样一种方式，它有long-polling的优势，同时能减少在有消息可读的情况下由Broker主动push消息给Consumer，减少不必要的请求。
消息中间件的Consumer实现
在消息中间件的Consumer中会有一个Buffer来缓存从Broker获取的消息，而用户的消费线程从这个Buffer中获取消费来消息，获取消息的线程和消费线程通过这个Buffer进行数据传递。
pull线程从服务端获取数据，然后写入到Buffer
consume线程从Buffer获取消息进行消费
有这个Buffer的存在，是否可以在long-polling请求时将Buffer剩余空间告知给Broker，由Broker负责推送数据。此时Broker知道最多可以推送多少条数据，那么就可以控制推送行为，不至于冲垮Consumer。
上面这幅图是akka的Dynamic Push/Pull示意图，思路就是每次请求会带上本地当前可以接收的数据的容量，这样在一段时间内可以由Server端主动推送消息给请求方，避免过多的请求。
akka的Dynamic Push/Pull模型非常适合应用到Consumer获取消息的场景。
Broker端对Dynamic Push/Pull的处理流程大致如下：
收到long-polling请求
while(有数据可以消费&请求没超时&Buffer还有容量) {
读取一批消息
Push到Consumer
Buffer-PushedAmount 即减少Buffer容量
}
response long-polling请求
结束（等待下一个long-polling再次开始这个流程）
Consumer端对Dynamic Push/Pull的处理流程大致如下：
收到Broker的响应：
if (long-polling的response) {
将获取的消息写入Buffer
获取Buffer的剩余容量和其他状态
发起新的long-polling请求
} else {
// Dynamic Push/Pull的推送结果
将获取的消息写入到Buffer（不发起新的请求）
}
举个例子：
Consumer发起请求时Buffer剩余容量为100，Broker每次最多返回32条消息，那么Consumer的这次long-polling请求Broker将在执行3次push(共push96条消息)之后返回response给Consumer（response包含4条消息）。
如果采用long-polling模型，Consumer每发送一次请求Broker执行一次响应，这个例子需要进行4次long-polling交互（共4个request和4个response，8次网络操作；Dynamic Push/Pull中是1个request，三次push和一个response，共5次网络操作）。
总结：
Dynamic Push/Pull的模型利用了Consumer本地Buffer的容量作为一次long-polling最多可以返回的数据量，相对于long-polling模型减少了Consumer发起请求的次数，同时减少了不必要的延迟（连续的Push之间没有延迟，一批消息到Consumer的延迟就是一个网络开销；long-polling最大会是3个网络开销）。
Dynamic Push/Pull还有一些需要考虑的问题，比如连续推送的顺序性保证，如果丢包了怎么处理之类的问题，有兴趣可以自己考虑一下（也可以私下交流）。
结语
本篇内容比较了Push、Poll、Long-Polling、Dynamic Push/Pull模型。
Push模型实时性好，但是因为状态维护等问题，难以应用到消息中间件的实践中。
Pull模式实现起来会相对简单一些，但是实时性取决于轮训的频率，在对实时性要求高的场景不适合使用。
Long-Polling结合了Push和Pull各自的优势，在Pull的基础上保证了实时性，实现也不会非常复杂，是比较常用的一种实现方案。
Dynamic Push/Pull在Long-Polling的基础上，进一步优化，减少更多不必要的请求。但是先对实现起来会复杂一些，需要处理更多的异常情况。
参考内容：Google->Reactive Stream Processing with Akka Streams
