分布式消息中间件（五）——MQ基础详解

一、消息队列MQ基础

1、MQ核心组成

     Sender（Producer App）——Message Queue——Receiver（Consumer App）

2、MQ vs SOA

     消息队列的出现意于完成系统间的消息通信，协调系统调用间调用。这跟SOA类似。但不同于SOA面向服务的直接调用，消息队列的通信不是直接调用关系，系统间通信主要通过消息发送，接收方接收消息，进行处理，完成与发送方的调用处理。

3、消息队列的优势

（1）系统解耦

     交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。

（2）提高系统响应时间

     例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。

（3）为大数据处理架构提供服务

     通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

4、JAVA 消息服务——JMS

     Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 

     JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

（1）点对点

     消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。

     消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。 
（2）发布/订阅 

 

     消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

（3）P2P vs Pub/Sub

     queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。 
     topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝。

二、消息中间件消息模式的扩展

     与ActiveMQ 遵循JMS的点对点、发布订阅者消息模型不同，Kafka在JMS规范的pub/sub模式基础之上进行个性化设计。

     同样kafka使用pub/sub模型，生产者将消息发送到topic中，topic中的消息可供n个消费者使用。

     不同之处在于，kafka将每个topic中的数据再细粒度化，提出分区partition概念；同时将单个消费者实例以消费组的角色消费数据，1个分区对应1个消费组中某一消息实例。提高了多个消费者同时处理分区中数据的并发效率。

     另外kafka有别于JMS规范或其他分布式消息系统的不同之一，kafka支持将消息持久化处理。这在接下来的文章中会具体介绍。