J2EE企业级项目开发-3期（KC007） 消息中间件 3.4 消息中间件文档.doc

3.4 消息中间件 简介 消息中间件的价值 消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。 通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 消息中间件的定义? 中间件就是 非业务的技术类组件。 其实从广义来说 操作系统上，业务系统下与业务无关的 ，都是中间件，包括数据库，离线等。 透过示例看消息中间件对应用的解耦? 互联网时代的消息中间件? 从目前互联网对消息中间件的需求来看应该分为两种类型， 一种是和钱相关的需求，一种是和钱无关的需求；和钱相关的需求消息的可靠性是放在第一位的，和钱无关的需求是速度放在第一位的，但这两种需求又是矛盾的，很难设计出一种既可靠又高效的系统，除非将两套方案捏合成一个系统，通过配置来选择不同方案，但从实现上说还是两种实现。 所以目前业界有几种不同的设计方式来满足不同的需求。 如何解决消息发送一致性? 用过JMS的都知道，JMS的API种，有很多XA开头的接口。其实如果不实用XA系列的接口实现，那么我们就无法直接得到发送消息给消息中间件及业务操作这两个事情的事物保证，而JMS中定义的XA系列的接口就是为了实现分布式事务的支持（发送消息和业务操作很难做在一个本地事务中）。但是会有如下问题: 1.引入了分布式事务，这会带来一些开销并增加复杂性。 2.对于业务操作有限制，要求业务操作的资源必须支持XA协议，才能够与发送消息一起来做分布式事务。这会成为一个限制，因为并不是所有需要与发送消息一起做成分布式事务的业务操作都支持XA协议。 其他的办法？ JMS可以解决一致性问题，但是存在一些限制并且成本相对较高。那么有没有其他的办法呢？ 可能这个过程当中会出现很多异常，下面具体分析下 那么如何了解业务操作的结果呢？ 下面展示了这个过程。由消息中间件主动询问业务应用，获取待处理消息所对的业务操作的结果，然后业务应用需要对业务操作结果进行检查，并且把结果发送给消息中间件，然后根据这个结果，更新状态。 如何解决消息中间件与使用者的强依赖问题? SOA(面向服务架构)大潮正在席卷着整个世界，而且势不可挡。 作为一种集成企业应用的方法论，SOA具备灵活性、标准性、重用性强和成本低等优点。厂商也一再强调，通过SOA，用户可以将所有组件服务简单组合在一起，这些服务可以被共享、重用和连接，从而实现更高效的企业业务集成应用。 消息模型对消息接收的影响? 消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 消息订阅者订阅消息的方式? 1.点对点模型（PTP） 点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发动到由某个名字标识的特定消费者。这个名字实际上对应于消息服务中的一个队列（Queue），在消息传动给消费者之前它被存储在这个队列中。队列可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。 2.发布-订阅模型（Pub/Sub） 发布-订阅模型用称为主题（topic）的内容分层结构代替了PTP模型中的惟一目的地，发送应用程序发布自己的消息，指出消息描述的是有关分层结构中的一个主题的信息。希望接收这些消息的应用程序订阅了这个主题。订阅包含子主题的分层结构中的主题的订阅者可以接收该主题和其子主题发表的所有消息。 保证消息可靠性的做法 生产者端保证 生产者的端的消息确认机制的设置,生产者配置 发送端支持无确认、主分区确认 (主分区收到消息后发送确认回执)、以及主备分区确认(备用分区消息同步后主分区才发送确认回执)三种机制 配置项acks: producer需要server接收到数据之后发出的确认接收的信号，此项配置就是指procuder需要多少个这样的确认信号。此配置实际上代表了数据备份的可用性。以下设置为常用选项： （1）acks=0： 设置为0表示producer不需要等待任何确认收到的信息。副本将立即加到socket buffer并认为已经发送。没有任何保障可以保证此种情况下server已经成功接收数据，同时重试配置不会发生作用（因为客户端不知道是否失败）回 馈的offset会总是设置为-1； （2）acks=1： 这意味着至少要等待leader已经成功将数据写入本地log，但是并没有等待所有follower是否成功写入。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。 （3）acks=all： 这意味着leader需要等待所有备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。 （4）其他的设置，例如acks=2也是可以的，这将需要