一、队列模型
最初的一种消息模型，消息的顺序是生产者发送的顺序，如果有多个消费者消费同一个队列，消费者之间是竞争关系，每条消息只会发送到一个消费者消费；
问题
如果一条消息要被多个消费者消费，如一份订单数据，风控系统、分析系统、支付系统等都需要接收消息。这个时候，单个队列就满足不了需求，一个可行的解决方式是，为每个消费者创建一个单独的队列，让生产者发送多份
缺点：浪费资源、生产者知道有多少消费者、违背了消息队列解耦的设计初衷
二、发布-订阅模型
与队列相比，发布者就是生产者，订阅者就是消费者，主题就是队列，他们之间最大的区别就是：一份消息能不能被消费多次
三、rabbitmq消息模型
他是少数坚持使用队列消息模型，通过exchange维护消费者和队列之间的关系来解决多消费者问题；生产者并不关心有多少消费者
四、rocketMq消息模型
标准的发布订阅模型，但是也有队列的概念，并且是一个非常重要的概念；
发布-订阅存在问题
请求-确认机制
几乎所有的消息队列都使用了朴素的的”请求-确认机制“，不管是在消费端或者生产端，发送消息后需要确认后才会发送下一条消息，否则重发；这样会存在消费或者生产消息不能并行而阻塞的问题，影响总体消费性能；
rocketmq如何解决问题
每个主题包含多个队列，通过多个队列来实现多实例生产消费
rocketmq 只能在队列层保证消息的有序性，不能在主题层保证
消费组
一个消费组相当于发布-订阅中的一个订阅者，消费组之间不受影响，同组内一条消息保证只会被一个消费者消费，每个消费组在组内的每个队列上维护了一个消费位置；
五、kafka消息模型
和rocketmq消息模型完全一致，我刚刚讲的所有 RocketMQ 中对应的概念，和生产消费过程中的确认机制，都完全适用于 Kafka。唯一的区别是，在 Kafka 中，队列这个概念的名称不一样，Kafka 中对应的名称是“分区（Partition）”，含义和功能是没有任何区别的。
内容来源说明：文章中的部分内容以及图片来自《极客时间-消息队列高手课》，写文章目的只是作为学习后的总结和整理
