消息队列：业务模型

队列模型

• 先进先出。如果需要将消息发给多个消费者，要求每个消费者都能收到全量消息。则需要未每个消费者单独创建队列，这种做法很蠢，且违背了消息队列解耦的原则。
  

发布订阅模型

• 发布者将消息发送到主题，订阅者在接收消息前需要订阅主题。订阅在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。
  

Rabbit的消息模型

• Exchange模块位于生产者和队列之间，生产者将消息发给Exchange，由Exchange上配置的策略来决定将消息投递到哪些队列。
• 同一份消息如果需要被多个消费者来消费，需要配置 Exchange 将消息发送到多个队列，每个队列中都存放一份完整的消息数据。
  

RocketMQ的消息模型

• 几乎所有消息队列产品都引入了请求-确认机制，确保消息不会丢失。
• 在生产端，生产者将消息发送给服务端，也就是Broker，服务端接收到消息并将消息写入主题或者队列后，给生产者回复确认。如果生产者没有收到确认或者收到失败的响应，则进行重试。
• 在消费端，消费者在收到消息并完成消费业务逻辑后，也会给服务端发送消费成功的确认，服务端只有收到消费确认后，才认为消息被成功消费。否则服务端会进行重试，直到收到对应的消费成功确认。
• 这个机制同时也带来了一个问题，为了保障消息的有序性，在某一条消息被成功消费之前，下一条消息是不能被消费的，否则就会出现消息空洞，违背了有序性这个原则。
• Rocket通过每个主题包含多个队列，通过多个队列来实现多实例并行生产和消费的方式来解决这个问题。在队列上保证消息的有序性，主题层面是不保证消息的严格顺序的。
• 
• 同一个消费组内的消费者是竞争关系。 不同消费组之间消费进度不受影响。
• 消费完的消息并不会立即被删除，这就需要 RocketMQ 为每个消费组在每个队列上维护一个消费位置（Consumer Offset），这个位置之前的消息都被消费过，之后的消息都没有被消费过，每成功消费一条消息，消费位置就加一。

Kafka的消息模型

• 和RocketMQ一样，只不过Kafka管队列叫分区（Partition）。