浅谈ActiveMq(上)
2018-01-14 23:28
169 查看
1.ActiveMq是什么?
首先解释MQ,mq:message queue 顾名思义就是消息队列。MQ是一种跨进程的通信机制,用于在上下游之间传递消息。MQ是一种常见的上下游“逻辑解耦+物理解耦”的消息通信服务,消息发送上游只需要依赖MQ,逻辑上和物理上都不用依赖其他服务。
MQ有什么用呢,首先先了解一个知识点(敲黑板),java线程节点间的通信依靠的是两种方式。一是共享内存,这个大家应该都知道,比如我们常用的线程锁、信号量都是这种形式的,二就是消息传递,而MQ就是实现消息传递的一种形式。介绍ActiveMq之前,还要在介绍一个知识点,就是JMS:java message service,Java消息服务,J2EE中的一个技术。JMS定义了Java中访问消息中间件的接口,并没有给予实,实现JMS接口的消息中间件成为JMS Provider。
现在可以介绍ActiveMq了,ActiveMq:Apache推出的,开源的,完全支持JMS和J2EE规范的JMS Provider实现的消息中间件(Message-Oriented Middleware, MOM)。实现JMS Provider,来帮助实现高可用、高性能、可伸缩、易用和安全的企业级面向消息服务的系统。ActiveMq的特点,多协议:TCP、SSL、NIO、UDP等、可插拔的体系结构,可以灵活定制、保证高性能的集群、支持消息持久化等。
MQ简单的介绍了一下,但为什么要是用MQ呢,首先来看下面两个图。
第一个模式是传统的模式,A同步发送数据给B,等待B执行结束,响应A,这种场景,A 和B绑定在一起了,有强耦合关系。而解耦的一个很好的方法,就是使用MQ,当A不关心B的返回值的时候,我们就可以使用第二种方式了。这样实现的异步消息,类似于手机短信,发送者不用等待消息接收者响应,减少软件多系统继承的耦合度,也保证了可靠性,MQ可以确保消息在中间件可靠保存,只有接收到后才删除消息,多个消息可以组成原子事务。
MQ的应用场景有哪些呢,比如异步处理、应用解耦、流量削锋、日志处理、消息通讯等,举个例子,当发送消息方关系执行结果,但接收方执行时间较长,这个应该怎么设计呢。
当调用方请求向接收方发送请求时,接收方会同步的返回调用成功,执行完成之后,通过网关调用MQ,由MQ来统一发送消息结果。为什么这么做,而不是接收方直接回复结果给调用方呢,首先不应该由回调网关来调用上游来通知结果,如果是这样的话,每次新增调用方,回调网关都需要修改代码,仍然会反向依赖,使用回调网关+MQ的方案,新增任何对微信支付的调用,都不需要修改代码,只需要调用方去订阅MQ即可。再有就是流量削峰的时候可以使用MQ,当一些秒杀活动,同时多个请求进来,通过MQ来保存消息,不需要业务端进行流量的控制,保证系统稳定、可用。
总之,关心下游执行结果呢,就使用RPC,不关心下游执行结果,就是用MQ。
而MQ缺点是什么呢。首先系统更复杂,多了一个MQ组件;其次是消息传递路径更长,延时会增加;而后是消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证;最后上游无法知道下游的执行结果。
首先解释MQ,mq:message queue 顾名思义就是消息队列。MQ是一种跨进程的通信机制,用于在上下游之间传递消息。MQ是一种常见的上下游“逻辑解耦+物理解耦”的消息通信服务,消息发送上游只需要依赖MQ,逻辑上和物理上都不用依赖其他服务。
MQ有什么用呢,首先先了解一个知识点(敲黑板),java线程节点间的通信依靠的是两种方式。一是共享内存,这个大家应该都知道,比如我们常用的线程锁、信号量都是这种形式的,二就是消息传递,而MQ就是实现消息传递的一种形式。介绍ActiveMq之前,还要在介绍一个知识点,就是JMS:java message service,Java消息服务,J2EE中的一个技术。JMS定义了Java中访问消息中间件的接口,并没有给予实,实现JMS接口的消息中间件成为JMS Provider。
现在可以介绍ActiveMq了,ActiveMq:Apache推出的,开源的,完全支持JMS和J2EE规范的JMS Provider实现的消息中间件(Message-Oriented Middleware, MOM)。实现JMS Provider,来帮助实现高可用、高性能、可伸缩、易用和安全的企业级面向消息服务的系统。ActiveMq的特点,多协议:TCP、SSL、NIO、UDP等、可插拔的体系结构,可以灵活定制、保证高性能的集群、支持消息持久化等。
MQ简单的介绍了一下,但为什么要是用MQ呢,首先来看下面两个图。
第一个模式是传统的模式,A同步发送数据给B,等待B执行结束,响应A,这种场景,A 和B绑定在一起了,有强耦合关系。而解耦的一个很好的方法,就是使用MQ,当A不关心B的返回值的时候,我们就可以使用第二种方式了。这样实现的异步消息,类似于手机短信,发送者不用等待消息接收者响应,减少软件多系统继承的耦合度,也保证了可靠性,MQ可以确保消息在中间件可靠保存,只有接收到后才删除消息,多个消息可以组成原子事务。
MQ的应用场景有哪些呢,比如异步处理、应用解耦、流量削锋、日志处理、消息通讯等,举个例子,当发送消息方关系执行结果,但接收方执行时间较长,这个应该怎么设计呢。
当调用方请求向接收方发送请求时,接收方会同步的返回调用成功,执行完成之后,通过网关调用MQ,由MQ来统一发送消息结果。为什么这么做,而不是接收方直接回复结果给调用方呢,首先不应该由回调网关来调用上游来通知结果,如果是这样的话,每次新增调用方,回调网关都需要修改代码,仍然会反向依赖,使用回调网关+MQ的方案,新增任何对微信支付的调用,都不需要修改代码,只需要调用方去订阅MQ即可。再有就是流量削峰的时候可以使用MQ,当一些秒杀活动,同时多个请求进来,通过MQ来保存消息,不需要业务端进行流量的控制,保证系统稳定、可用。
总之,关心下游执行结果呢,就使用RPC,不关心下游执行结果,就是用MQ。
而MQ缺点是什么呢。首先系统更复杂,多了一个MQ组件;其次是消息传递路径更长,延时会增加;而后是消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证;最后上游无法知道下游的执行结果。
相关文章推荐
- ActiveMQ之浅谈一
- 浅谈jms之(通过spring整合activeMQ实现jms)实例
- ActiveMQ点对点模式的浅谈
- 浅谈jms之(用activemq实现jms实例)
- 浅谈Spring Boot 整合ActiveMQ的过程
- 浅谈对ActiveMQ的理解
- 浅谈jms之中间件(mom)activeMQ的安装和部署
- ActiveMQ多个消费者监听一个列队,最后是谁消费了?
- 浅谈Android之SurfaceFlinger相关介绍(二)
- 浅谈 struts2 之 chain
- 浅谈EF框架(一)
- 浅谈对梯度下降的理解
- 浅谈HTTP中Get与Post的区别
- iOS开发之浅谈MVVM的架构设计与团队协作
- 浅谈持续集成
- 浅谈以数据结构的视角去解决算法问题的步骤
- 浅谈JAVA集合框架(转载)_常用的Vector和HashMap
- Spring boot 集成Activemq
- 浅谈大型网站动态应用系统架构