1、消息中间件的应用场景 

(1)异步通讯  (2)解耦  (3)并发缓冲  2、消息发送和投递的不可靠性  (1)分布式网络进行就引入了数据传输的不确定性  (2)也就是CAP理论中的P（分区容错性）  (3)跨网络通信产生了分布式事务问题  3、消息发送一致性  (1)是指产生消息的业务动作与消息发送的一致  (2)也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息。  4、一致性如何保障？  假设这儿有两部操作  a、支付订单处理 b、 发送会计原始凭证（发送消息）  问题？  如果业务操作成功，执行消息发送前应用故障，消息发不出去，导致消息丢失（订单系统与会计系统的数据不一致）  如果业务操作成功，应用正常，但消息系统故障或网络故障，也会导致消息发不出去（订单系统与会计系统的数据不一致）；  5、JMS标准中的XA协议方式是否可以保障消息发送一致性？  (1)JMS协议标准中的API中，有很多以XA开头的接口，其实就是支持XA协议（两阶段提交协议）的全局事务型接口。  (2)JMS中的XA系列接口，可以提供分布式事务支持。  (3)但引用了XA方式的分布式事务，又会带来很多的局限  ①要求业务操作的资源必须支持XA协议（并不是所有资源都支持XA）  ②两阶段提交协议的成本  ③持久化成本等DYP模型的局限性（全局锁定，成本高，性能低）  (4)引入XA违背了柔性事务的初衷！  6、变通的做法  (1)主动方应用先把消息发送给消息中间件，消息状态标记为待确认;  (2)消息中间件收到消息之后，把消息持久化到消息存储中，但并不向被动方应用投递消息；  (3)消息中间件返回消息持久化结果（成功，或者失效），主动方应用根据返回结果进行判断如何处理业务操作处理；  ①失败：放弃业务操作处理，结束（必须向上层返回失败结果）  ②成功：执行业务操作处理  (4)业务操作完成后，把业务操作结果（成功/失败）发送给消息中间件；  (5)消息中间件收到业务操作结果后，根据结果进行处理；  ①失败：删除消息存储中的消息，结束；  ②成功：更新消息存储中的消息状态为·待发送（可发送）·，紧接着执行消息投递；  (6)前面的正向流程都成功后，向被动方应用投递消息； 

版权声明：转载请注明出处http://write.blog.csdn.net/postlist