消息队列基本概念讲解

1. 主要用于分布式场景下，服务之间做异步通信的时候来使用，比如商城系统中
   商品上架的时候需要更新ES索引库的索引数据的，这时候商品微服务就需要异步通知搜索微服务更新索引数据

2. 消息队列应用场景
   异步处理、服务解耦、流量控制

3. 消息队列有两种模型：队列模型、发布/订阅模型

小结：队列模型每条消息只能被一个消费者消费，而发布/订阅模型就是为了一条消息能被多个消费者消费而生的
当然队列模型也可以通过消息全量存储到多个队列来实现一条消息被多个消费者消费，但是会有数据的冗余

4. 发布/订阅模型兼容队列模型，即只有一个消费者的情况下，和队列模型基本一致
   rabbitmq采用队列模型，rocketmq和kafka采用发布订阅模型

rabbitmq消息模型

rabbitmq中，生产者和队列之间有一层exchange模块，生产者并不关心将消息发往哪个队列
而是直接将消息发送给exchange模块，由exchange配置的策略决定将消息投递到哪些队列中去

rocketmq的消息模型是标准的发布/订阅模型

7. 几乎所有的消息队列产品都使用了一种【请求-确认机制】，生产者先将消息发送给服务端，也就是broker,
   服务端在收到消息并写入topic或队列中后，会给生产者发送确认的响应,如果生产者没有收到服务端的确认或者失败的响应
   生产者会重新发送

8. 在消费端，消费者在收到消息并完成自己的业务逻辑（比如将数据保存到数据库）后，也会给服务端发送消费成功的确认
   服务端只有收到消费确认后，才会认为一条消息被成功消费，否则会重新给消费者发送这条消息，直到收到消费者的消费成功确认

9. 多个生产者producer---topic主题（多个队列）---多个消费组（每个组多个消费者）
   该确认机制很好的保证了消息传递过程中的可靠性，但是确认机制在消费端带来了一个不小的问题，
   为了确保消息的有序性，在某一条消息在被成功消费之前，下一条消息是不能够被消费的，否则就会出现消息空洞，违背了有序性这个原则

也就是说，每个主题在任意时刻，至多只能有一个消费者实例在进行消费，那就没办法通过水平扩展消费者的数量来提上消费端的性能
为了解决这个问题，rocketmq在主题下面增加了队列的概念

每个主题包含多个队列，通过多个队列来实现多实例并行生产和消费，需要注意的是，rocketmq只在队列上保证了消息的有序性
主题层面无法保证消息严格顺序的

rocketmq中订阅者是通过消费组来体现的，每个消费组都消费主题中一份完整的信息，不同消费组之间消费进度互不影响
也就是说一条消息被customer group1消费过，也会再给customer group2消费

消费组中包含多个消费者，同一组内的消费者是竞争消费的关系，每个消费者负责消费组内的一部分消息
如果一条消息被customer01消费了，那么同组的其它消费者就不会再收到这条消息

在topic的消费过程中，由于消息需要被不同的组进行多次消费，所以消费完的消息并不会立即删除，
这就需要rocketmq为每个消费组在每个队列上维护一个消费位置customer-offset,
这个位置之前的消息都被消费过，之后的消息都没被消费过，每成功消费一条消息，消费位置+1
这个消费位置是非常重要的，我们在使用消息队列的时候，丢消息的原因大多是因为消息位置处理不当导致的

rocketmq中比较关键的概念就这些了，如下消息模型

kafka消息模型

我们再来看看常见的消息队列kafka，kafka的消息模型和rocketmq完全一致，刚刚讲的rocketqm中的概念
和生产消费过程中的确认机制完全适用于kafka, 唯一的区别是，在Kafka中，队列的这个名称不一样，
kafka中对应的名称交partition分片, 含义和功能没有任何区别

总结

1. 队列和主题的区别其实就是对应着两种消息模型：队列模型和发布/订阅模型，这两种模型并没有本质区别
   可通过一些扩展和变化来相互替代
2. rabbitmq采用的队列模型，但它一样可以实现发布/订阅功能，rocketmq和kafka采用的是发布/订阅模型
   并且二者的消息模型基本一致
   最后说一定上面讲的消息模型和相关概念是业务层面的模型，深刻理解业务模型可以让我们更好的使用消息队列
   rocketmq和kafka业务模型基本一致，但是底层实现完全不同的

为什么一个主题中药维护多个队列

1. 提高并发能力

参考文章