• 深入浅出JMS(一)——JMS简单介绍


          假设手机仅仅能进行实时通话,没有留言和短信功能会怎么样?一个电话打过来,正好没有来得及接上,那么这个电话要传递的信息肯定就收不到了。为什么不能先将信息存下来,当用户须要查看信息的时候再去获得信息呢?伴随着这个疑惑,短息和留言应运而生,不管手机是否开机、是否未及时接到,我们都能得到当中的信息。JMS提供了相似这种功能,本章我们将系统的学习JMS中的相关重要内容。

    clip_image004

          Ø 掌握JMS基本概念及适用范围

          Ø 点对点模型与公布/订阅模型的差别和使用场合

          Ø 熟悉核心和通用的JMS API

          Ø 熟悉并理解JMSclient开发的步骤

          Ø 消息的同步和异步接收的实现方式

          Ø 串包问题的解决的方法

    企业消息系统

          Java Message Service是由Sun开发的,它为 Java程序提供一种訪问企业消息系统的方法。在讨论JMS之前,我们分来析一下企业消息系统。
          企业消息系统,即面向消息的中间件(MOM),提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送,即应用程序彼此不直接通信,而是与作为中介的MOM 通信。MOM提供了有保证的消息发送,应用程序开发者无需了解远程过程调用(PRC)和网络/通信协议的细节。ActiveMQ正是MOM中优秀的一员。

    企业消息系统的优点

    我们先来看看下图,应用程序A将Message发送到server上,然后应用程序B从server中接收A发来的消息,通过这个图我们一起来分析一下JMS的优点

    image

    图 1 JMS通讯示意图

    提供消息灵活性

          应用程序A与应用程序B通过使用MOM的应用程序编程接口(API)发送消息进行通信。MOM 将消息路由给应用程序B,这样消息就能够存在于MOM中,MOM 负责处理网络通信。假设网络连接不可用,MOM会存储消息,直到连接变得可用时,再将消息转发给应用程序B。
          灵活性的还有一方面体如今,当应用程序A发送其消息时,应用程序B甚至能够不处于运行状态。MOM将保留这个消息,直到应用程序B開始运行并试着检索消息为止。这还防止了应用程序A由于等待应用程序B检索消息而出现堵塞。
          这样的异步通信要求应用程序的设计与如今大多数应用程序不同,只是对于时间无关或并行处理,它可能是一个极事实上用的方法。

    松散耦合

          企业消息系统的真正威力在于应用程序的松散耦合。在上面的图中,由应用程序A发送消息指定一个特定目标,如“订单处理”。而如今,是由应用程序B提供订单处理功能。
          可是在将来,我们能够用不同的订单处理程序替换应用程序B,应用程序A将不再是明智之选。替换应用程序将继续发送消息完毕“订单处理”,而消息也仍将得到处理。
          相同,我们也能够替换应用程序A,仅仅要替换应用程序继续发送消息进行“订单处理”,订单处理程序就无需知道是否有一个新的应用程序在发送订单。

    JMS是什么

          JMS是一系列的接口及相关语义的集合,通过这些接口和和当中的方法,JMSclient怎样去訪问消息系统,完毕创建、发送、接收和读取企业消息系统中消息。
          在JMS之前,每一家MOM厂商都用专有API为应用程序提供对其产品的訪问,通常可用于很多种语言,当中包含Java语言。JMS通过MOM为Java程序提供了一个发送和接收消息的标准的、便利的方法。用JMS编写的程序能够在不论什么实现JMS标准的MOM上执行。
          JMS可移植性的关键在于:JMS API是由Sun作为一组接口而提供的。提供了JMS功能的产品是通过提供一个实现这些接口的提供者来做到这一点的。开发者能够通过定义一组消息和一组交换这些消息的应用程序,建立JMS应用程序,实现异步通讯。

    JMS的目标

          JMS从提出以来,致力于完毕例如以下几个目标:
    定义一组消息公用概念和有用工具。
         
    全部Java应用程序都能够使用JMS中定义的API去完毕消息的创建、接收与发送,不论什么实现了JMS标准的MOM都能够作为消息的中介,完毕消息的存储转发。
    最大化消息应用程序的可移植性。
         
    MOM提供了有保证的消息发送,应用程序开发者无需了解远程过程调用(PRC)和网络/通信协议的细节,提供了程序的可移植性。
    最大化减少应用程序与应用系统之间的耦合度。
         
    因为MOM的存在,各个应用程序仅仅关心和MOM之间怎样进行消息的接收与发送,而无需关注MOM的还有一边,其它程序是怎样接收和发送的。

    JMS两种消息模型

    JMS提供了两种消息通信模型:

          Ø 点到点(P2P)模型

          Ø 公布/订阅(Pub/Sub)模型

    clip_image010

    图 2 JMS通讯模型

    从图中能够看出,ClientA和ClientB是消息生产者,通过两种不同的目的地分别向ClientC、ClientD、ClientE和ClientF发送消息。
          在ClientA、C、D之间的消息是点对点模型,使用这样的模型,client发送消息到队列目的地(Queue),从这个队列里面仅仅有一个消息接收者能够收到那个消息,其它訪问同一目的地的接收者不会接收到该消息。如ClientC接收Queue中的Msg1消息,ClientD接收Queue中的Msg2消息。
          在ClientB、E、F之间的消息是公布/订阅模型。使用这样的广播模型,一个client发送消息给主题目的地(Topic),不论什么数量的消费订阅者能够从这个主题目的地来接收它们。如:ClientE和ClientF都接收这个Msg3这条消息。

    点到点模型

    点对点传递模型:生产者发送消息到一个特定的队列(Queue)中,而消费者从一个消息队列中得到消息,例如以下图所看到的:

    image

    图 3 点到点通讯模型示意图

    点对点模型的特点:

    Ø  每条消息有一个消费者

          每条仅仅有一个消费者,假设一条消息被消息者接收,那么其它的消费者就不能得到这条消息了。

    Ø 发送和接受消息与时间没有关系

          也就是说,生产者在发送消息后,消费者能够在随意的时刻接收,但有两个前提:

                1、消息未过期

                2、消息没有被其它的用户接收

          消费者也能够先执行,当生产者一执行,将消息发送到队列中,消费者就可以从队列中获得消息,这叫“守株待兔“。

    Ø  消费者必须确认对消息的接收

          收到消息后消费者必须确认消息已被接收,否则JMS服务提供者会觉得该消息没有被接收,那么这条消息仍然能够被其它人接收。程序能够自己主动进行确认,不须要人工干预。

    Ø  非持久的消息最多仅仅发送一次

          非持久的消息最多仅仅发送一次,表示消息有可能未被发送,造成未被发送的原因可能有:

                1、 JMS服务提供者出现宕机等情况,造成非持久信息的丢失

                2、 队列中的消息过期,未被接收

    Ø  持久的消息严格发送一次

          我们能够将比較重要的消息设置为持久化的消息,持久化后的消息不会由于JMS服务提供者的故障或者其它原因造成消息丢失。

    公布/订阅模型

          公布/订阅模型:公布/订阅传递消息类型与主题(Topic)有关。生产者公布消息,而消费者订阅感兴趣的消息,生产者将消息和一个特定的主题(Topic)连在一起,消息传递系统(MOM)依据消费者注冊的兴趣,将消息传递给消费者。这样的类型很相似出版报纸、杂志的形式,例如以下图所看到的:

    image

    图 4 公布/订阅通讯模型示意图

    公布/订阅模型的特点:

    Ø  每一个消息都能够有多个(0,1,……)订阅者

          每条消息能够有多个消费者,假设报纸和杂志一样,谁订阅了谁都能够获得。

    Ø  订阅者仅仅能消费他们订阅之后出版的消息

          这就要求订阅者必须先订阅,生产者再公布。即订阅者必须先执行,再等待生产者的执行,这和点对点类型有所差异。

    Ø  订阅者必须保持为活动状态才干使用这些消息

          即订阅者必须保持活动状态等待公布者公布的消息,假设订阅者在公布者公布消息之后才执行,则不能获得先前公布者公布的消息。

  • 相关阅读:
    flume sink两种类型 file_rool 自定义sing com.mycomm.MySink even if there is only one event, the event has to be sent in an array
    为什么引入进程20年后,又引入线程?
    As of Flume 1.4.0, Avro is the default RPC protocol.
    Google Protocol Buffer 的使用和原理
    Log4j 2
    统一日志 统一订单
    网站行为跟踪 Website Activity Tracking Log Aggregation 日志聚合 In comparison to log-centric systems like Scribe or Flume
    Percolator
    友盟吴磊:移动大数据平台的架构、实践与数据增值
    Twitter的RPC框架Finagle简介
  • 原文地址:https://www.cnblogs.com/bhlsheji/p/4384217.html
Copyright © 2020-2023  润新知