回答重点：

消息队列主要有两种模型：队列模型和发布/订阅模型。

1，队列模型也叫点对点模型，消息从生产者发送到队列，每条消息只能被一个消费者消费一次，消费之后消息就从队列中删除了。多个消费者之间是竞争关系，谁抢到算谁的。这种模型适合任务处理类场景，比如订单处理、任务分发这些，一个任务只需要一个处理者执行就行。

2，发布/订阅模型是生产者把消息发布到某个主题Topic，所有订阅了这个Topic的消费者都会收到这条消息。每个订阅者收到的是相同的消息副本，适合广播通知、实时推送、日志分发这类场景。

队列模型:一个生产者发消息到队列，多个消费者竞争消费，每条消息只被一个消费者处理。

发布/订阅模型:一个生产者发消息到Topic，多个订阅者各自独立收到消息副本。

二者简单示意图：

扩展：

队列模型

        生产者往某个队列里面发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者，但是消费者之间是竞争关系，即每条消息只能被一个消费者消费。
打个比方，队列模型就像是一对一聊天，我发给你的消息只会在你的聊天窗口弹出，不可能弹出到别人的聊天窗口中。

发布/订阅模型

         为了解决一条消息能被多个消费者消费的问题，发布/订阅模型就来了。该模型是将消息发往一个Topic（主题）中，所有订阅了这个Topic的订阅者都能消费这条消息。
可以这么理解，发布/订阅模型等于我们都加入了一个群聊，我发一条消息，加入了这个群聊的人都能收到这条消息。
         那有人说，我一对一聊天对每个人都发同样的消息不就也实现了一条消息被多个人消费了嘛?
是的，通过多队列全量存储相同的消息，即数据的冗余可以实现一条消息被多个消费者消费。
       RabbitMQ就是采用队列模型，通过Exchange模块来将消息发送至多个队列，解决一条消息需要被多个消费者消费的问题。
       从这还能知道，假设群聊里除我之外只有一个人，那么此时的发布/订阅模型和队列模型其实就一样了。

kafka的消费者组机制

        Kafka和RocketMQ用的是发布/订阅模型，但它们引入了消费者组的概念来实现负载均衡。同一个消费者组内的消费者会分摊消费同一个Topic的消息，组内每条消息只会被一个消费者处理，这就实现了队列模型的效果。不同消费者组之间互相独立，各自消费完整的消息副本，这就是发布/订阅的效果。举个例子，订单Topic有3个分区，订单服务消费者组有3个实例，每个实例负责消费一个分区。同时数据分析服务也订阅了这个Topic，它们是另一个消费者组，也能收到全量的订单消息。

两种模型对比

       需要注意的是，发布/订阅模型可以兼容队列模型，只要订阅者只有一个的情况下就和队列模型基本一致了。RabbitMQ采用队列模型，RocketMQ和 Kafka采用发布/订阅模型。RabbitMQ的发布/订阅模式在本质上依然是基于队列模型的，只是通过引入多队列和交换机的绑定，同时将消息发给多个队列，模拟出消息发布/订阅的效果。

面试官追问

1，Kafka里一个消费者组的消费者数量能超过分区数吗?超过了会怎样?
回答：可以超过，但超过的消费者会处于空闲状态，分不到任何分区。Kafka的分区和消费者是一对一绑定的，一个分区在同一个消费者组内只能被一个消费者消费。所以消费者数量最多等于分区数才能充分利用，多了就是浪费资源。如果想提升消费能力，得先扩分区数。

2，RabbitMQ是队列模型，那它怎么实现发布/订阅的效果?

回答：靠Exchange这个组件。生产者把消息发给Exchange，Exchange根据绑定规则把消息路由到一个或多个队列。如果是fanout类型的Exchange，消息会被广播到所有绑定的队列，每个队列后面挂一个消费者，这样每个消费者都能收到同样的消息，就实现了发布/订阅的效果。本质上是通过消息冗余存储到多个队列来实现的。

3，如果一个消费者消费太慢，会影响同组其他消费者吗?

回答：在Kafka和RocketMQ里不会直接影响，因为每个消费者负责自己的分区，各消费各的。但如果这个慢消费者负责的分区消息积压了，整体的消费进度就会被拖慢。另外如果触发了rebalance，比如这个慢消费者被判定为死亡，它的分区会被重新分配给其他消费者，可能会导致短暂的消费停顿。

4，消费者组的offset是怎么管理的?
回答：早期 Kafka把 offset存在ZooKeeper 里，后来改成存在 Kafka内部一个特殊的 Topic 叫__consumer_offsets里。消费者每消费一批消息就提交一次offset，告诉broker自己消费到哪了。提交方式有自动提交和手动提交，自动提交简单但可能丢消息或重复消费，手动提交能精确控制但代码复杂一点。RocketMQ的offset 管理机制类似，也是broker端存储消费进度。