应用场景
- 服务解耦
也就是解决服务之间的拆分及其调用，这里主要看服务之间是强依赖还是弱依赖。
如果是强依赖，我们采用的是直连的一种方式，比如同步的Dubbo调用，同步的Http、Springcloud调用，或者Jrpc都可以。
如果是弱依赖，我们就可以去选用消息中间件，去做消息的解耦。弱依赖不代表着说可以失败，如果说不允许失败，就需要上游的服务去做一个可靠性的投递了，这点以后再细说。
- 削峰填谷
如果说你有一些即时性很高，业务量很大的这种场景，比如说秒杀啊、大促啊，如何去对应用服务做一个抗压，就需要把流量的高峰和低谷做一个平衡。MQ最早就是做这么一个场景。
- 异步化缓冲
有些业务逻辑可以做一些异步化的操作，只需要做到最终一致性即可，类似于这种柔性的事务。
应用的思考点：
- 生产端的可靠性投递
- 消费端幂等
- MQ本身特性：高可用、低延迟、可靠性、消息堆积能力、可扩展性（消息队列无感知扩容）等等。
技术选型思考点：
- 各个MQ的性能、优缺点、相应的业务场景。
- 集群架构模式，分布式、可扩展、高可用、可维护性。
- 集群规模和人员成本。
- 未来规划。
JMS规范
JMS（Java Message Service）规范，也就是Java消息服务，它定义了Java中访问消息中间件的接口的规范。在这里注意哦，JMS只是接口，并没有给予实现，实现JMS接口的消息中间件称为 “JMS Provider”，目前知名的开源 MOM （Message Oriented Middleware，也就是消息中间件）系统包括Apache的ActiveMQ、RocketMQ、Kafka，以及RabbitMQ，可以说他们都 “基本遵循” 或 “参考” JMS规范，都有自己的特点和优势。
首先要了解JMS规范里最经典的两种消息投递模式，即 “点对点” 与 “发布订阅”。
点对点：生产者向队列投递一条消息，只有一个消费者能够监听得到这条消息（PTP)，下图所示：
发布订阅：生产者向队列投递一条消息，所有监听该队列的消费者都能够监听得到这条消息（P/S)，下图所示：
