消息中间件的模型总结

推拉模型

首先推拉模型是针对 消息中间件的实现和策略，而非客户端及调用方。

推模型： 是有中间件将消息主动推送给消费者。推模型很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的，而非客户端，所以可能会有消息堆积。推模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。推模型实时性较好，收到数据后可立即发送给客户端

Kafka 作为日志的消息中间件，肯定受不了这种模式，日志都堆积在消息中，所以它是推模型。

拉模型：是消费者主动去中间件拉起消息，客户端(指一个connection,一般情况指一个tcp的连接建立)连接到broker之后，启动一个线程，这个线程的任务就是循环调用方法从broker中拉取相应的消息至本地。如果是同步方法调用获取则将相应的消息存放在本地内存中，当同步方法消费消息时，则从该内存区中直接获取相应的消息进行消费；此模型broker无需维护维护消费者的状态，而且可以确保一个消息被准确的消费了。此模型的性能应该相对推模型来说更优，因为中间件只需要保存消息和更新消息状态即可。在互联网上大吞吐量的消息队列都是采用拉模式。

订阅发布 与 消息队列

订阅发布是一对多模型，一个消息由多个消费者订阅，在订阅发布中，中间件收到消息，就会 多向多个消费者进行推送，在一般情况下，不保证消费者一定能接受到该消息。只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了，所以在一般情况下，订阅发布是没办法支持ACK的。但针对RabbtMQ 他有Exchange，可以将订阅发布 转成 队列，这样也就解决了订阅发布的缺点。

消息队列 是一个队列，一处消费（没说一个消费者），只要一处已经消费，则不再发送。 所以消息消费者不可能消费到已经被消费的消息，而且一个消费者只能一处消费