前言
上一篇说明了一下，消息队列的用处和使用场景。这篇给大家简单介绍一下它的一些基本概念。
一、消息队列的基本概念
1.1 Broker
Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。
1.2 消息生产者和消费者
- 消息生产者Producer：发送消息到消息队列。
- 消息消费者Consumer：从消息队列接收消息。
1.3 消息模型
点对点消息队列模型
消息生产者向一个特定的队列发送消息，消息消费者从该队列中接收消息。
消息的生产者和消费者可以不同时处于运行状态。
每一个成功处理的消息都由消息消费者签收确认（Acknowledge）。如图：
发布订阅消息模型-Topic
发布订阅消息模型中，支持向一个特定的主题Topic发布消息，0个或多个订阅者接收来自
这个消息主题的消息。在这种模型下，发布者和订阅者彼此不知道对方。实际操作过程中，
必须先订阅，再发送消息，而后接收订阅的消息，这个顺序必须保证。
1.4 消息顺序性保证
基于Queue消息模型，利用FIFO先进先出的特性，可以保证消息的顺序性。
1.5 消息的ACK确认机制
即消息的Ackownledge确认机制：
为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer
确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。
如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个
消息重新发送给其他的Consumer重新消费处理。
1.6 消息的持久化
消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列
宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。
1.7 消息的同步和异步收发
- 同步
消息的收发支持同步收发的方式
同步收发场景下，消息生产者和消费者双向应答模式，例如：张三写封信送到邮局中转站，
然后李四从中转站获得信，然后在写一份回执信，放到中转站，然后张三去取，当然张三
写信的时候就得写明回信地址。
消息的接收如果以同步的方式(Pull)进行接收，如果队列中为空，此时接收将处于同步阻
塞状态，会一直等待，直到消息的到达。 - 异步
消息的收发同样支持异步方式：异步发送消息，不需要等待消息队列的接收确认。
异步接收消息，以Push的方式触发消息消费者接收消息。
1.8 消息的事务支持
消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、
处理，这处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。
二、JMS消费服务
Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向
消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
点对点与发布订阅最初是由JMS定义的。
这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)
JMS规范目前支持两种消息模型：
- 点对点（point to point， queue）
- 发布/订阅（publish/subscribe，topic）
2.1 点对点：Queue，不可重复消费
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。
Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
P2P模式包含三个角色：
- 消息队列（Queue）
- 发送者(Sender)
- 接收者(Receiver)
每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，
直到他们被消费或超时。
2.2 发布/订阅：Topic，可以重复消费
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。
和点对点方式不同，发布到topic的消息会被所有订阅者消费。
支持订阅组的发布订阅模式：
发布订阅模式下，当发布者消息量很大时，显然单个订阅者的处理能力是不足的。实际上现实
场景中是多个订阅者节点组成一个订阅组负载均衡消费topic消息即分组订阅，这样订阅者很
容易实现消费能力线性扩展。可以看成是一个topic下有多个Queue，每个Queue是点对点的
方式，Queue之间是发布订阅方式。
2.3 区别
- 点对点模式
生产者发送一条消息到queue，一个queue可以有很多消费者，但是一个消息只能被一个消费者
接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者，所以Queue实现了
一个可靠的负载均衡。 - 发布订阅模式
发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。topic实现了发布和订阅，
当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到
这个消息的拷贝。
三、流行模型对比
传统企业型消息队列ActiveMQ遵循了JMS规范，实现了点对点和发布订阅模型，但其他流行的
消息队列RabbitMQ、Kafka并没有遵循JMS规范。
3.1 RabbitMQ
RabbitMQ实现了AQMP协议，AQMP协议定义了消息路由规则和方式。生产端通过路由规则发送消息
到不同queue，消费端根据queue名称消费消息。
RabbitMQ既支持内存队列也支持持久化队列，消费端为推模型，消费状态和订阅关系由服务端负责
维护，消息消费完后立即删除，不保留历史消息。
点对点
生产端发送一条消息通过路由投递到Queue，只有一个消费者能消费到。
多订阅
当RabbitMQ需要支持多订阅时，发布者发送的消息通过路由同时写到多个Queue，不同订阅组消费
不同的Queue。所以支持多订阅时，消息会多个拷贝。
3.2 Kafka
Kafka只支持消息持久化，消费端为拉模型，消费状态和订阅关系由客户端端负责维护，
消息消费完后不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份
就可以了。但是可能产生重复消费的情况。
参考文章:
https://blog.csdn.net/heyutao007/article/details/50131089
https://www.cnblogs.com/tianqing/p/7110468.html