RabbitMQ消息模型
少数依然坚持使用队列模型的产品之一。怎么解决多消费者问题的？
RabbitMQ中，Exchange位于生产者和队列间，生产者并不关心将消息发给哪个队列，而将消息发送给Exchange，由Exchange策略决定将消息投递到哪些队列。
同份消息若需被多消费者消费，需配置Exchange将消息发到多个队列，每个队列都存放一份完整消息数据，可为一个消费者提供消费服务。这也可变相实现发布-订阅模型的“一份消息数据可被多订阅者多次消费”功能。
RocketMQ的消息模型
RocketMQ使用标准的发布-订阅模型，其中的生产者、消费者、主题与前文讲的发布-订阅模型中的概念一致。
RocketMQ还有队列概念，又有何作用？
几乎所有MQ都使用一种非常朴素的“请求-确认”机制，确保消息不会在传递过程中由于网络或服务器故障而丢失。
具体做法也简单。
- 生产者先将消息发给服务端（即Broker），服务端在收到消息并将消息写入主题或队列后，给生产者发送确认的响应。
- 若生产者未收到服务端的确认或收到失败的响应，则重新发送；
- 消费者在收到消息并完成消费业务逻辑（比如将数据保存到数据库）后，也会给服务端发消费成功的确认，服务端只有收到消费确认后，才认为一条消息被成功消费，否则它会给消费者重发送这条消息，直到收到对应的消费成功确认
确认机制保证消息传递过程中的可靠性，但该机制在消费端带来不小问题。
为确保消息的有序性，在某条消息被成功消费前，下条消息是不能被消费的，否则就会出现消息空洞，违背有序性原则。
即每个主题在任意时刻，至多只能有一个消费者实例在进行消费，那就没法通过水平扩展消费者数量提升消费端总体的消费性能。为解决问题，RocketMQ在主题下增加队列概念。
每个主题包含多个队列，通过多队列实现多实例并行生产和消费。注意RocketMQ只在队列保证消息有序性，主题层面无法保证消息的严格顺序。
RocketMQ中，订阅者的概念是通过消费组（Consumer Group）体现。
每个消费组都消费主题中一份完整消息，不同消费组间消费进度彼此不受影响，即一条消息被Consumer Group1消费过，也会再给Consumer Group2消费。
角色完全相同的消费者被分组在一起，称为消费组。通过它，在消息消费方面实现负载平衡和容错非常容易。
Consumer Group的Consumer实例必须具有完全相同的主题订阅。
消费组包含多个消费者，同组的消费者是竞争消费关系，每个消费者负责消费组内的一部分消息。若一条消息被Consumer1消费，那同组的其他消费者就不会再收到该消息。
在Topic的消费过程，由于消息需要被不同组进行多次消费，所以消费完的消息并不会立即被删，这需要RocketMQ为每个消费组在每个队列维护一个消费位置（Consumer Offset），该位置之前的消息都被消费过，之后消息都未被消费过，每成功消费一条消息，消费位置加一。
这个消费位置是非常重要的概念，丢消息的原因大多是由于消费位置处理不当导致。
- RocketMQ的消息模型的核心概念
在消费时，为保证消息的不丢失和严格顺序，每个队列只能串行消费，无法做到并发，否则会出现消费空洞的问题。那如果放宽一下限制，不要求严格顺序，能否做到单个队列的并行消费呢？如果可以，该如何实现？
todo
Kafka的消息模型
RocketMQ的完全一致，上节所有RocketMQ中对应的概念，和生产消费过程中的确认机制，都完全适用于Kafka。
唯一区别：
Kafka中，队列概念的名称不一样，Kafka中对应的名称分区（Partition），本质毫无差异。
总结
队列和主题的区别，这俩概念的背后实际对应两种不同的消息模型：队列模型和发布-订阅模型。这两种消息模型其实并无本质区别，都可通过一些扩展或者变化来互相替代。
- RabbitMQ采用的是队列模型，但是它一样可以实现发布-订阅功能
- RocketMQ和Kafka采用的是发布-订阅模型，并且二者的消息模型是基本一致的。
本文消息模型相关概念都是业务层面模型，但业务模型不等于实现层面模型。
比如MySQL和Hbase都是支持SQL的数据库，它们的业务模型中，存放数据的单元都是“表”。
但在实现层面，没有哪个数据库是以二维表方式存储数据，MySQL使用B+树，HBase使用KV结构。
同理，像Kafka和RocketMQ的业务模型基本一样，并非指实现就一样，实际俩实现完全不同。
参考
