activeMQ消息中间件

1、 消息中间件分布式说明书 第 一 章 中间件选型1.1 KafkaKafka是linkedin开源的MQ系统，主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，0.8开始支持复制，不支持事务，适合产生大量数据的互联网服务的数据收集业务。1.2 RabbitMQRabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护。1.3 RocketMQ 阿里巴巴的MQ中间件，

2、在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费，可以在broker端进行消息过滤.1.4 ActiveMQActiveMQ是Apache下的一个子项目。历史悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jm

3、s轻松融合，实现了多种协议，如Ajax，REST，Stomp等，支持持久化到数据库，少量代码就可以高效地实现高级应用场景， 可以很好的运行在任何JVM上，而不只是集成到JBoss的应用服务器中，对spring有很好的支持，支持大量的跨语言客户端。1.5 ZeroMQZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码。Ac

4、tiveMQ消息中间件的选择从以下方面进行考虑：（1）activemq可以很好的运行在任何JVM上，而不只是集成到JBoss的应用服务器中；（2）activemq支持大量的跨语言客户端；（3）activemq支持许多不同的协议，如Ajax，REST，Stomp，OpenWire，XMPP（4）activemq支持许多高级功能，例如MessageGroups，ExclusiveConsumer，CompositeDestinations（5）activemq支持可靠连接并且具有可配置的自动重连接（6）activemq对spring有很好的支持（7）activemq支持跨网络的分布式目的地（8）a

5、ctivemq是速度非常快；一般要比jbossmq快10倍（9）群集(Cluster)：为了简化点对点通讯模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。 一、activeMQ主要的几类部署方式比较1、默认的单机部署（kahadb）activeMQ的默认存储的单机方式，以本地kah

6、adb文件的方式存储，所以性能指标完全依赖本地磁盘IO，不能提供高可用。 2、基于zookeeper的主从（levelDB Master/Slave）5.9.0新推出的主从实现，基于zookeeper来选举出一个master，其他节点自动作为slave实时同步消息。因为有实时同步数据的slave的存在，master不用担心数据丢失，所以leveldb会优先采用内存存储消息，异步同步到磁盘。所以该方式的activeMQ读写性能都最好，特别是写性能能够媲美非持久化消息。优点：实现高可用和数据安全性能较好缺点：因为选举机制要超过半数，所以最少需要3台节点，才能实现高可用。 3、基于共享数据库的主从（

7、Shared JDBC Master/Slave）可以基于postgres、mysql、oracle等常用数据库。每个节点启动都会争抢数据库锁，从而保证master的唯一性，其他节点作为备份，一直等待数据库锁的释放。因为所有消息读写，其实都是数据库操作，activeMQ节点本身压力很小，性能完全取决于数据库性能。优点：实现高可用和数据安全简单灵活，2台节点就可以实现高可用缺点：稳定性依赖数据库性能依赖数据库 第 二 章 实现MQ分布式2.1.1 Master/Slave集群搭建-传统式 Kahadb是activemq从版本5.4之后的默认消息存储引擎一般activemq的Master Slav

8、e是基于KAHADB的阻塞来做的，先看一下原理· 把master conf 目录中的jetty.xml中的端口改成8161· 把slave conf 目录中的jetty.xml中的端口改成8162此时把master和slave先后启动，其实你也可以不用管顺序，谁先启动谁会先把<kahaDB directory=“/localhost/kahadb”/>中的db lock住，它就成了mater，而此时另一个实例会处于“pending”状态。当master宕机后slave会自动启动转变为master。当宕掉的master再次被启动后然后变成slave挂载在原先的sl

9、ave下面变成slave2.1.2 Master/Slave集群搭建-基于ZooKeeperReplicated LevelDB Store方式 这种主备方式是ActiveMQ5.9以后才新增的特性，使用ZooKeeper协调选择一个node作为master。被选择的master broker node开启并接受客户端连接。其他node转入slave模式，连接master并同步他们的存储状态。slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的slaves。如果master死了，得到了最新更新的slave被允许成为master。failed node能够重新加入到网络中并

10、连接master进入slave mode。所有需要同步的disk的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。所以，如果你配置了replicas=3，那么法定大小是(3/2)+1=2. Master将会存储并更新然后等待 (2-1)=1个slave存储和更新完成，才汇报success。至于为什么是2-1，熟悉Zookeeper的应该知道，有一个node要作为观察者存在。单一个新的master被选中，你需要至少保障一个法定node在线以能够找到拥有最新状态的node。这个node将会成为新的master。因此，推荐运行至少3个replica nodes，以防止一个node失败

11、了，服务中断。 从ActiveMQ5.10开始出现了使用ZooKeeper来进行Master/Slave搭建的模式。 搭建时请务必注意下面几个问题：1 参于master slave组网的配置中<broker xmlns=“/schema/core” brokerName=“zk_cluster_nodes“必须一至。2 ActiveMQ至少需要3个实例（2N+1公式），只要不符合2N+1，master slave集群会发生集群崩溃。 搭建ZooKeeper，你可以搭建3个ZooKeeper实例也可以只用1个，如果出于高可用性考虑建议使用3

12、台ZooKeeper。 下载ZK，我们在这边使用的是“zookeeper-3.4.6”，把它解压到服务器上，在其conf目录下生成zoo1.cfg文件 ，内容如下： 在ZK的data目录下建立一个目录，名为“1”，并在其下建立一个文件，文件名为“myid”并使其内容为1 以server.A=B:C:D的形式指定三台服务器 A - 数字，表示服务器的编号 B - 服务器的ip C - 服务器与集群中的Leader服务器交换信息的端口 D - 用来执行选举时服务器相互通信的端口（万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leade 如果你需要在本地搭建2N+

13、1的ZooKeeper，那你必须依次在data目录下建立2、3两个文件夹并且在每个文件夹下都有一个myid的文件，文件的内容依次也为2，3，然后把下面注释掉的3行server.1 server.2 server.3前的#注释符放开。因此data目录下的目录名和myid中的内容对应的就是server.x这个名字。ü 核心配置以下是传统的Master/Slave配置ü 基于ZK的配置（添加基于replicatedLevelDB的持久化配置）2.1.3 Master/Slave集群搭建-Broker Cluster搭建所谓cluster即负载匀衡，它负载的是“用户”的请求，此处的

14、用户就是调用端cluster的用法就是用来分散用户的“并发”请求的。前面説过，ActiveMQ的Cluster有两种：1 动态式(multicast）2 静态式（static）在实际应用场景中”静态方式“被大量使用，动态式使用的是multicast即组播式，基本已被淘汰。ü 核心配置ü 在61616中的配置ü 在61617中的配置ü 客户端的配置2.1.4 Master/Slave集群搭建-Broker Cluster和Master Slave对比优点· 自动分发调用端请求· 流量分散缺点当调用端连接上任意一个节点发送了一条消息，比如

15、说往NODE A发送了一条消息。此时消费端还没来得及消费NODE A上的消息该节点就发生宕机了。此时调用端因为有failover所以它会自动连上另一个节点（NODE B）而该节点上是不存在刚才“发送的消息”的，因为刚才发送到NODE A的消息只在NODE A上，没有同步到NODE B上。因为只有Master Slave会做主从间的消息同步，这是一个致命伤。2.1.5 MASTER SLAVE+BROKER CLUSTER的搭建 考虑到消费端可能会发生：当Group1中有未消费的数据时时，消费端此时被转派到了Group2中的任意一个节点。l master/slave模式下，消息会被逐个复制l 而

16、cluster模式下，请求会被自动派发l 我们使用ZK搭建MASTER SLAVEl 我们使用BROKER CLUSTER把两个“组”合并在一起先来看下面的集群规划Ø Group1的配置由于这涉及到两个组6个ActiveMQ的实例配置，如果把6个配置全写出来是完全没有必要的，因此我就把配置分成两组来写吧。每个组的配置对于其组内各个节点都为一致的，除去那些个端口号。Group1的配置（保持6个实例中brokerName全部为一致）可以看到这边的broker cluster的配置是用来确保每一台都可以和Group2中的各个节点保持同步Ø Group2的配置 可以看到这边的bro

17、ker cluster的配置是用来确保每一台都可以和Group1中的各个节点保持同步2.1.6 MASTER SLAVE+BROKER CLUSTER的搭建-客户端2.1.7 MASTER SLAVE+BROKER CLUSTER的搭建-实验1、先把所有实例进程全部杀掉2、把6台实例全部启动起来3、把客户端写上全部6台实例4、使用生产端任意发送30条消息5、生产端连上了61616与61619（ctivemqa1、activemqa2），发送了30条消息，61616和61619收到信息，消费端消息进行消费6、然后我们把61616、61619所属的activemqa1、activemqa2的进程直

18、接杀了7、然后运行消费端，消费端连上了61617、61619，activemqb1、activemqb2成为master，控台显示无任何消息消费8、再重启activemqa1、activemqa2，杀掉activemqb1、activemqb2，此时activemqc1、activemqc2成为master，控台显示无任何消息消费9、ok第 三 章 实现MQ持久化3.1 MQ持久化配置修改3.1.1 持久化为数据库 在activemq的conf目录下的activemq.xml，找到 <persistenceAdapter> <kahaDB directory="$a

19、ctivemq.base/data/kahadb"/> </persistenceAdapter> 把它注释掉换成： <persistenceAdapter> <jdbcPersistenceAdapter dataSource="#oracle-ds"/> </persistenceAdapter> 此处是以持久化到oracle为例，因此需要引用把oracle的驱动jar包，并在在activemq.xml的 <bean></beans>里面增加数据库的配置，如下： 运行activemq，可以发现自动创建了三张表： 1、activemq_acks用于存储订阅关系。如果是持久化Topic，订阅者和服务器的订阅关系在这个表保存。 2、activemq_lock此表用于主从模式锁定，当第一个activemq服务器启动后会锁住此表成为master，第二