ActiveMQ消息队列从入门到实践（1）—JMS的概念和JMS消息模型

1. 面向消息的中间件

1.1 什么是MOM

面向消息的中间件，Message Oriented Middleware，简称MOM，中文简称消息中间件，利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。

一个MOM系统，通常会包括客户端（Clients）、消息（Message）和 MOM，客户端是发送或者接受消息的应用程序，消息封装了要传递的内容，MOM可以存储和转发消息。如下图所示，系统A和系统B之间的消息传递，不是直接通信，而是通过中间件来间接的传递。

1.2 MOM的好处

降低系统间通信复杂度

有了MOM，系统间的通信，不用考虑系统是什么语言开发的，也不用考虑复杂的网络编程，各个系统只需要关心自身和MOM之间如何进行消息的接受和发送即可，这些操作通过简单的API就可以完成。

 

提高了消息的灵活性

系统A通过MOM向系统B发送消息，消息可以存储在MOM中，并由MOM转发。即使是系统B不在线，MOM会持有这个消息，直到系统B连接并处理消息。

这就是说，系统A发完消息后，就可以执行其它操作，而不必阻塞等待，尤其是对那些时间无关或者并行处理的操作，非常适用。

 

松散耦合

有了MOM的存在，对于系统B而言，只要发送的消息没有变化，就不必考虑系统Ａ的变化。A系统的代码改变，不会影响到B系统，反之亦然。

 

2. JMS概念

2.1 JMS是什么

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。

Java消息服务的规范包括两种消息模式，点对点和发布者／订阅者。Java消息服务支持同步和异步的消息处理。

 

一个JMS系统，通常包括了以下部分：

JMS Client，java语言编写的客户端，用于发送和接受消息。

Non-JMS Client，使用消息系统本地API编写的客户端，而不是使用JMS API。

Message，消息，被定义，用于在不同的客户端之间交换。

JMS Provider，JMS提供商，是消息系统（比如ActiveMQ），当然，即可以支持JMS，也可以同时支持Non-JMS。

Administered Objects，被管理的对象，预置的JMS对象，为客户端使用。

 

2.3 JMS规范

JMS规范只是定义了接口，并没有实现，规范全文见：JSR 914: JavaTM Message Service (JMS) API 。

 

3. JMS模型简介

3.1 JMS支持两种消息通信模型：

点对点模型(Point to Point，P2P)

发布者/订阅者模型（publish/subscribe，  pub/sub）

P2P模型中，Sender把一个消息发送到Queue中，这个消息只能由一个客户端消费；一旦消息被消费，其它客户端就不能从这个Queue中获取到消息。巧克力糖盒子里只有一块糖，只有最先打开的那个人能吃到，后来的人就吃不到了。

Pub/Sub模型中，一个消息主题（Topic）被发布以后，可以有多个订阅者收听，这些订阅者都可以获取到消息；前提是，订阅者订阅了这个主题，并且只能接受订阅以后的消息。这就像生活里的期刊订阅，我们只能收到订阅以后的期刊，之前的期刊，杂志社是不可能投递给我们的。

 

3.2 点对点模型

只有一个消费者：每条消息只有一个消费者，如果这条消息被消费，那么其它消费者不能接受到此消息。

时间无关性：消息的消费和时间无关，只要消息被发送了，在消息过期之前，如果没有其他消费者消费了这个消息，那么客户端可以在任何时候来消费这条消息。

消费者必须确认：消费者收到消息之后，必须向Message Provider确认，否则会被认为消息没有被消费，仍然可以被其他消费者消费。可以设置自动确认。这个特点其实也是保证一条消息只能由一个消费者来消费。

 

非持久化的消息只发一次：非持久化的消息，可能会丢失，因为消息会过期，另外Message Provider可能宕机。

持久化的消息严格发一次：消息可以被持久化，比如持久化在文件系统或者数据库中，这样可以避免Message Provider的异常或者其它异常导致消息丢失。

 

3.3 发布者/订阅者模型

每条消息可以有多个订阅者，订阅者只能消费它们订阅topic之后的消息。

非持久化订阅，订阅者必须保持为活动状态才能使用这些消息，如果一个订阅者A断开了10分钟，那么A就会收不到这10分钟内的消息。持久化订阅，Message Provider会保存这些消息，即使订阅者因为网络原因断开了，再重新连接以后，能让消费这些消息。是否使用持久化订阅，需要根据业务场景判断。

来源地址：https://blog.yoodb.com/yoodb/article/detail/1541