MQ是一个实现JMS技术规范的面向消息中间件（Message-oriented middleware），这种中间件的总体思想就是作为消息发送器和消息接收器之间的消息中介，在较大程度上进行松耦合。我们常见的消息中间件有ActiveMQ,RabbitMQ,kafka。ActiveMQ属于是老牌的消息中间件，使用java语言编写，与spring能够很好的集成。
一、消息中间件使用场景
1.系统解耦合
使用MQ来连接A系统和B系统，A系统宕机了不会影响B系统的正常运行，两个系统互不干涉，两者的耦合度降低。
2.流量削峰
现在很多的项目都使用了dubbo框架，消费者调用生产者，使用了生产者提供的服务，但是如果某一时间同时有几百万个服务请求，就会出现高并发的情景。而消息中间件就能够很好的处理这种情景下可能出现的弊端。每个请求过来都先给MQ发一个消息，然后请求就保存在了MQ中，服务器会从MQ中获取请求消息（消费请求），再提供相应的服务。这样能够大大降低服务器的压力。避免性能瓶颈问题。这也是我们常说的流量削峰
二、ActiveMQ为什么需要集群
首先了解服务消息服务集群优点：
1.解决单点故障
想想如果项目中只部署了一个消息服务，如果这个服务宕机不工作了，那整个项目也就无法进行正常的运转。消息服务集群部署之后，如果一台服务出现故障，还有其他服务器可以提供服务。对项目运转影响很小。
2.高可用
Master Slave 模式可以实现高可用，Broker Clusters 模式可以实现负载均衡。
3.提高服务能力
activeMQ集群是横向增加服务器来提高服务性能，服务器越多，它的服务能力也就越强
三、ActiveMQ集群部署方式
1.Broker Clusters 模式：多个broker之间同步消息，已达到服务器负载的可能。
2.Master Slave 模式【主从模式】：当主服务器宕机时，备用服务器可以立即补充，以保证服务能够正常运转。
四、ActiveMQ的主从集群部署
1.shared filesystem Master-Slave部署方式（基于共享文件kahadb）
activeMQ默认消息持久化，消息存储在data目录下的kahadb文件中，此种方式就是基于共享文件KahaDB来实现主服务和从服务的信息热备，所有的MQ服务器都不断的去争夺data目录下kahadb的控制权，谁抢到谁就是主服务，其他都成为从服务，只有主服务才能对kahadb进行读写操作，如果主服务出现故障，剩下的从服务谁抢到kahadb的控制权，谁就成为主服务器并接着上个主服务器继续提供服务。这里可以看出，从服务器其实就是主服务器的备胎。
2.shared database Master-Slave部署方式（基于数据库）
这种方式和第一种基于共享文件方法差球不多。只是基于共享的介质由文件变成了数据库
3.Replicated LevelDB Store（重点）
这种方式与前面两种有所区别，我们不再去配置共享文件目录或者共享数据库了，这种方式是通过zookeeper自动将主服务器中存放消息的目录中的数据同步到了从服务器中。
前面两种方式都是所有MQ服务器自己争夺共享目录或者共享数据库的的控制权，从而上位成为主服务器，但是这种方式谁成为主服务器是由zookeeper投票机制决定的。
如果想要zookeeper投票机制能够正常运行，那么zookeeper至少需要3个，所以zookeeper我们也需要集群部署。另外如果activeMQ能够正常运行的不到半数，那么也无法通过zookeeper投票产生主服务器（如：现在有3台MQ服务，半数就是1.5，如果有2台及以上MQ能够正常运行，那么可以通过投票机制产生主从服务，如果小于1.5也就是只有1台能正常运行，投票机制就不好使了）
ActiveMQ的集群配置:
activemq.xml文件中:
<persistenceAdapter>
<replicatedLevelDB
directory="${activemq.data}/leveldb" replicas="3" bind="tcp://0.0.0.0:0" zkAddress="192.168.0.101:2181" zkPassword="" hostname="ymklinux" sync="local_disk" />
</persistenceAdapter> replicas 集群中存在的节点的数目
bind:哪个节点是主，就指定该节点的端口，进行数据复制的，0.0.0.0代表任意的ip，0代表任意算口
现在项目中除了ActiveMQ之外，另外一种消息中间件RabbitMQ也较为常见：https://blog.csdn.net/qq_43655835/article/details/102459278