MOM思想就是A和B两个应用程序不直接发送消息。之前A和B直接发送消息有很多效率问题，如A发送之后B没有及时接受，那么A就一直再在那里堵塞并发性不好，A必须等B接受完之后有返结果了A才可以结束。而MOM就是为了解决这样的问题，不让A与B之间交互，在A和B之间加一个消息中间件，A把消息放到消息中间上，就可以走了，去做别的事情，B什么时候来消息中间件取消息A不用知道也不用管。这样就提高了效率提供并发性，等B去走后可以通过状态，通知，回调等方式通知A就可以。市面上实现这种思想的技术有很多，IBM（MQSEVICES）、Microsoft(MSMQ）以及BEA的MessageMQ等。处于百家争鸣阶段都是各自实现各自的，没有统一实现标准。此时SUN为了实现统一标准就出现了JMS统一实现规范。JMS主要有2种消息模型，点到点和发布订阅两种。
消息队列是在消息的传输过程中保存消息的容器，用于接收消息并以文件的方式存储，一个消息队列可以被一个也可以被多个消费者消费。
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
目前在生产环境，使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
下面详细介绍一下消息队列在实际应用中常用的使用场景。场景分为异步处理、应用解耦、流量削锋和消息通讯四个场景。
场景说明用户注册后，需要发送注册邮件和发送注册信息，传统的做法有两种：串行方式并行方式
串行方式
将注册信息写入数据库成功后，发送注册邮件，然后发送注册短信，而所有任务执行完成后，返回信息给客户端
并行方式
由上可以看出，传统串行和并行的方式会受到系统性能的局限，那么如何解决这个问题？我们需要引入消息队列，将不是必须的业务逻辑，异步进行处理，由此改造出来的流程为
场景说明用户下单后，订单系统需要通知库存系统。
传统的做法为：订单系统调用库存系统的接口。如下图所示：
如何解决上述的缺点呢？需要引入消息队列，引入消息队列后的架构如下图所示：
假如在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其后续操作了。由此实现了订单系统与库存系统的应用解耦。
流量削峰也是消息对列中的常用场景，一般在秒杀或团抢活动中使用广泛。
应用场景秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。
流量削锋处理方式系统图如下：
日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。
日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。架构简化如下：
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列、聊天室等。
在点对点通讯架构设计中，客户端A和客户端B共用一个消息队列，即可实现消息通讯功能。
客户端A、客户端B、直至客户端N订阅同一消息队列，进行消息的发布与接收，即可实现聊天通讯方案架构设计。
讲消息队列就不得不提JMS。JMS(JavaMessageService，Java消息服务)JMS叫做Java消息服务（JavaMessageService）,是Java平台上有关面向MOM的技术规范，旨在通过提供标准的产生、发送、接收和处理消息的API简化企业应用的开发，类似于JDBC和关系型数据库通信方式的抽象。
API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建，发送，接收和读取消息。他是分布式通信耦合度更低，消息服务更加可靠以及异步性。
在EJB架构中，有消息bean可以无缝的与JM消息服务集成。在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。
在JMS标准中，有两种消息模型P2P（PointtoPoint），Publish/Subscribe（Pub/Sub）
P2P（点对点）模式包含三个角色：消息队列（Queue），发送者（Sender），接收者（Receiver）。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，知道他们被消费或者超时。
P2P消息域使用queue作为Destination，消息可以被同步或异步的发送和接收，每个消息只会给一个Consumer传送一次。Consumer可以使用MessageConsumer.receive()同步地接收消息，也可以通过使用MessageConsumer.setMessageListener()注册一个MessageListener实现异步接收。
多个Consumer可以注册到同一个queue上，但一个消息只能被一个Consumer所接收，然后由该Consumer来确认消息。并且在这种情况下，Provider对所有注册的Consumer以轮询的方式发送消息。
P2P的特点
包含三个角色：主题（Topic），发布者（Publisher），订阅者（Subscriber）。多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
除非显式指定，否则topic不会为订阅者保留消息。当然，这可以通过持久化（Durable）订阅来实现消息的保存。这种情况下，当订阅者与Provider断开时，Provider会为它存储消息。当持久化订阅者重新连接时，将会受到所有的断连期间未消费的消息。
Pub/Sub的特点
在JMS中，消息的产生和消费都是异步的。对于消费来说，JMS的消息者可以通过两种方式来小消费消息。
1.ConnectionFactory
创建Connection对象的工厂，针对两周不同的JMS消息模型，分别有QueueConnectionFactory和TopicConnectionFactory两种。可以通过JNDI来查找ConnectionFactory对象。
2.Destination
所以，Destination实际上就是两种类型的对象：Queue，Topic可以通过JNDI来查找Destination
3.Connection
Connection表示在客户端和JMS系统之间建立的链接（对TCP/IPSocket的包装）。Connection可以产生一个或多个Session。跟ConnectionFactory一样，Connection也有两种类型：QueueConnection和TopicConnection。
4.Session
Session是操作消息的接口。可以通过session创建生产者、消费者、消息等。Session提供了事务的功能。当需要使用session发送/接收多个消息时，可以将这些发送/接收动作放到一个事务中。同样，也分QueueSession和TopicSession。
5.消息的生产者
消息生产者由Session创建，并用于将消息发送到Destination。同样，消息生产者分两种类型：QueueSender和TopicPublisher。可以调用消息生产者的方法（send或publish方法）发送消息。
6.消息消费者
消息消费者由Session创建，用于接收被发送到Destination的消息。两种类型：QueueReceiver和TopicSubscriber。可分别通过session的createReceiver(Queue)或createSubscriber(Topic)来创建。当然，也可以session的creatDurableSubscriber方法来创建持久化的订阅者。
7.MessageListener
消息监听器。如果注册了消息监听器，一旦消息到达，将自动调用监听器的onMessage方法。EJB中的MDB（Message-DrivenBean）就是一种MessageListener。