分布式消息队列ActiveMQ

消息队列的使用场景

• 削峰填谷：当下游的数据处理不过来的时候，可以先把消息缓存到一个地方，再进行慢速消费
• 异步化缓冲：有些业务逻辑实时性要求不高，只需要做到最终一致性，类似柔性的事务
• 服务解耦：服务的拆分和隔离，需要看业务是强依赖还是弱依赖，如果是若依赖，就可以用MQ做一个消息的投递，但必须要保证上游投递的可靠性

应用的思考点

• 如何保证生产端的可靠性投递？
• 如何保证消费端的幂等性，即消息只能消费一次？

基础概念

专业术语

• JMS（Java Message Service）：实现JMS 接口的消息中间件， 定义了Java中访问消息中间件的接口的规范；
• Provider（MessageProvider）：消息的生产者；
• Consumer（MessageConsumer）：消息的消费者；
• PTP（Point to Point）：即点对点的消息模型，这也是非常经典的模型；
• Pub / Sub（Publish/Subscribe）：即发布/订阅的消息模型；
• Queue：队列目标，也就是我们常说的消息队列，一般都是会真正的进行物理存储；
• Topic：主题目标；
• ConnectionFactory：连接工厂，JMS 用它创建连接；
• Connection：JMS 客户端到JMS Provider 的连接；
• Destination：消息的目的地；
• Session：会话，一个发送或接收消息的线程（这里Session可以类比Mybatis的Session）；

JMS 消息格式定义

• StreamMessage 原始值的数据流
• MapMessage 一套名称/值对
• TextMessage 一个字符串对象
• BytesMessage 一个未解释字节的数据流
• ObjectMessage 一个序列化的Java对象

消息投递模型

点对点(Ponit To Point)

生产者向队列投递一条消息，只有一个消费者能够监听得到这条消息

发布/订阅(Pub/Sub)

生产者向队列投递一条消息，所有监听该队列的消费者都能够监听得到这条消息

四种主流的MOM

ActiveMQ（了解）

ActiveMQ各项指标

衡量一个MOM，我们主要从三方面考虑即可，即服务性能、存储堆积能力、可扩展性。

• ActiveMQ的性能一般，在早期传统行业为王的时代还是比较流行的，但现如今面对高并发、大数据的业务场景，往往力不从心
• 默认采用kahadb存储（索引文件形式存储），也可以使用高性能的google leveldb（内存数据库存储）， 或者可以使用MySql、Oracle进程消息存储（关系型数据库存储）
• ActiveMQ 可以与zookeeper进行构建 主备集群模型，并且多套的主备模型直接可以采用Network的方式构建分布式集群

ActiveMQ集群架构模式

ActiveMQ最经典的两种集群架构模式，Master-Slave 、Network 集群模式

• Master-Slave：顾名思义，就是主从方式，当然这里要理解为主备的方式，也就是双机热备机制；Master Slave 背后的想法是，消息被复制到slave broker，因此即使master broker遇到了像硬件故障之类的错误，你也可以立即切换到slave broker而不丢失任何消息。 Master Slave是目前ActiveMQ推荐的高可靠性和容错的解决方案。

• 架构思考：Master-Slave集群模型的关键点

  • 上图（Master-Slave）绿色的为主节点，灰色的则为备份节点，这两个节点都是运行状态的
  • zookeeper的作用就是为了当绿色的主节点宕机时，进行及时切换到备份的灰色节点上去，使其进行主从角色的互换，用于实现高可用性的方案
  • Master-Slave集群模型的缺点也显而易见，就是不能做到分布式的topic、queue，当消息量巨大时，我们的MQ集群压力过大，没办法满足分布式的需求

• Network
  

• Network：这里可以理解为网络通信方式，也可以说叫Network of brokers。这种方式真正解决了分布式消息存储和故障转移、broker切换的问题。可以理解消息会进行均衡；从ActiveMQ1.1版本起，ActiveMQ支持networks of brokers。它支持分布式的queues和topics。一个broker会相同对待所有的订阅（subscription）：不管他们是来自本地的客户连接，还是来自远程broker，它都会递送有关的消息拷贝到每个订阅。远程broker得到这个消息拷贝后，会依次把它递送到其内部的本地连接上

• 架构思考：Network集群模型的关键点：

  • 首先，这种方案需要两套或多套（Master-Slave）的集群模型才可以搞定，部署非常麻烦，需要两套或多套集群直接相互交叉配置，相互间能够感知到彼此的存在。下面我给出一段XML配置，简单来说就是在ActiveMQ的配置文件里要进行多套（Master-Slave）之间的 networkConnector配置工作：

  <broker brokerName="receiver" persistent="false" useJmx="false">
   	<transportConnectors>
   		<transportConnector uri="tcp://localhost:62002"/>
   	</transportConnectors>
   	<networkConnectors>
      	<networkConnector 
                uri="static:( tcp://localhost:61616,tcp://remotehost:61616)"/>
   	</networkConnectors>
  </broker>
  

  • 其次，Network虽然解决了分布式消息队列这个难题，但是还有很多潜在的问题，最典型的就是资源浪费问题，并且也可能达不到所预期的效果