是什么

消息中间件。可以在分布式系统的不同服务之间进行消息的发送和接收

它的出现解决了什么问题

可以让系统解耦
比如：使用消息中间件，某一个服务，可能依赖了其他好几个服务。比如课程里面的运营商后台依赖了4个服务，那不用mq就和4个服务耦合，用了mq，就只和1个mq耦合。参考下图：

实际项目应用场景

监听商品添加消息，接收消息，将对应的商品信息同步到索引库

每次添加完商品并将同步商品到索引库如果，如果直接同步数据库，当数据库很大的时候，会影响服务器性能，这时我们，就使用ActiveMQ消息中间件，后台添加完消息后，搜索服务器发送一个消息【商品id】，并将接收到的商品id在数据库中查找跟商品id有关的信息，吧信息添加到索引库中。

ActiveMQ的特点如下

完全支持JMS 1.1和J2EE 1.4规范（持久化，XA消息，事务）

支持多种传输协议：in-VM，TCP，SSL，NIO，UDP，JGroups，JXTA

可插拔的体系结构，可以灵活制定，如：消息存储方式，安全管理等

很容易和Application Server集成使用

多种语言和协议编写客户端，如：Java，C，C++，C#，Ruby，Perl，Python，PHP

从设计上保证了高性能的集群，客户端—服务器，点对点

可以很容易的和Spring结合使用

支持通过 JDBC 和 journal 提供高速的消息持久化

支持和Axis的整合

ActiveMQ消息发送失败

ActiveMQ有两种通信方式，点到点形式和发布订阅模式。

如果是点到点模式的话，如果消息发送不成功，此消息默认会保存到ActiveMQ服务端直到有消费者将其消费，所以此消息是不会丢失的。

如果是发布订阅模式的通信方式，默认情况只通知一次，如果接受不到此消息就没有了，这种场景使用于对消息发送率要求不高的情况，如果要求消息必须送达不可以丢失的话，需要配置持久订阅。每个订阅端定义一个id，在订阅是向ActiveMQ注册，发布消息和接受消息时需要配置发送模式为持久化，此时如果客户端接受不到消息，消息会持久化到服务端，直到客户端正常接收后为止。

如何防止消息重复发送

解决方法：增加消息状态表。

通俗来说就是一个账本，用来记录消息的处理状态，每次处理消息之前，都去状态表中查询一次，如果已经有相同的消息存在，那么不处理，可以防止重复发送。

什么情况下才使用ActiveMQ

多个项目之间集成：

跨平台

多语言

多项目

优点：

降低系统间模块的耦合度

解耦

软件扩展性

丢消息怎么办

解决方案：用持久化消息【可以使用对数据进行持久化JDBC，AMQ(日志文件)，KahaDB和LevelDB】，或者非持久化消息及时处理不要堆积，或者启动事务，启动事务后，commit()方法会负责任的等待服务器的返回，也就不会关闭连接导致消息丢失了。

持久化消息非常慢

默认的情况下，非持久化的消息是异步发送的，持久化的消息是同步发送的，遇到慢一点的硬盘，发送消息的速度是无法忍受的。但是在开启事务的情况下，消息都是异步发送的，效率会有2个数量级的提升。所以在发送持久化消息时，请务必开启事务模式。其实发送非持久化消息时也建议开启事务，因为根本不会影响性能。

服务挂掉

这得从ActiveMQ的储存机制说起。在通常的情况下，非持久化消息是存储在内存中的，持久化消息是存储在文件中的，它们的最大限制在配置文件的<systemUsage>节点中配置。但是，在非持久化消息堆积到一定程度，内存告急的时候，ActiveMQ会将内存中的非持久化消息写入临时文件中，以腾出内存。虽然都保存到了文件里，但它和持久化消息的区别是，重启后持久化消息会从文件中恢复，非持久化的临时文件会直接删除

Queue和Topic的区别

点对点（point-to-point，简称PTP）Queue消息传递模型：

在该消息传递模型下，一个消息生产者向消息服务器端一个特定的队列发送消息，一个消费者从该队列中读取消息。在这种模型下，消息生产者知道消息消费者的队列并直接将消息发送到消息消费者的队列。这种模型的特点是能够保证数据安全

发布/订阅（publish/subscribe，简称pub/sub）Topic消息传递模型：

在该消息传递模型下，一个消息发布者向一个特定的消息主题发布消息，0或多个对此消息主题感兴趣的并且处于活动状态的消息订阅者或者建立了持久订阅的消息订阅者才可以接收到所发布的消息。可能造成数据丢失

ActiveMQ【JMS的同步与异步】发送消息的方式有哪些

同步方式

两个通信应用服务之间必须要进行同步，两个服务之间必须都是正常运行的。发送程序和接收程序都必须一直处于运行状态，并且随时做好相互通信的准备。
发送程序首先向接收程序发起一个请求，称之为发送消息，发送程序紧接着就会堵塞当前自身的进程，不与其他应用进行任何的通信以及交互，等待接收程序的响应，待发送消息得到接收程序的返回消息之后会继续向下运行，进行下一步的业务处理。