分布式消息队列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虽然解决了分布式消息队列这个难题,但是还有很多潜在的问题,最典型的就是资源浪费问题,并且也可能达不到所预期的效果
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值