activeMQ消息中间件.docx
- 文档编号:14289623
- 上传时间:2023-06-22
- 格式:DOCX
- 页数:10
- 大小:20.68KB
activeMQ消息中间件.docx
《activeMQ消息中间件.docx》由会员分享,可在线阅读,更多相关《activeMQ消息中间件.docx(10页珍藏版)》请在冰点文库上搜索。
activeMQ消息中间件
消息中间件分布式
说明书
中间件选型
一.1Kafka
Kafka是linkedin开源的MQ系统,主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,0.8开始支持复制,不支持事务,适合产生大量数据的互联网服务的数据收集业务。
一.2RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:
AMQP,XMPP,SMTP,STOMP,也正因如此,它非常重量级,更适合于企业级的开发。
结合erlang语言本身的并发优势,性能较好,但是不利于做二次开发和维护。
一.3RocketMQ
阿里巴巴的MQ中间件,在其多个产品下使用,并能够撑住双十一的大流量,他并没有实现JMS规范,使用起来很简单。
部署由一个命名服务(nameserver)和一个代理(broker)组成,nameserver和broker以及producer都支持集群,队列的容量受机器硬盘的限制,队列满后可以支持持久化到硬盘(也可以自己适配代码,将其持久化到NOSQL数据库中),队列满后会影响吞吐量,可以采用主备来保证稳定性,支持回溯消费,可以在broker端进行消息过滤.
一.4ActiveMQ
ActiveMQ是Apache下的一个子项目。
历史悠久的开源项目,已经在很多产品中得到应用,实现了JMS1.1规范,可以和spring-jms轻松融合,实现了多种协议,如Ajax,REST,Stomp等,支持持久化到数据库,少量代码就可以高效地实现高级应用场景,可以很好的运行在任何JVM上,而不只是集成到JBoss的应用服务器中,对spring有很好的支持,支持大量的跨语言客户端。
一.5ZeroMQ
ZeroMQ号称最快的消息队列系统,尤其针对大吞吐量的需求场景。
ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用成功的挑战。
扩展性好,开发比较灵活,采用C语言实现,实际上他只是一个socket库的重新封装,如果我们做为消息队列使用,需要开发大量的代码。
ActiveMQ消息中间件的选择从以下方面进行考虑:
(1)activemq可以很好的运行在任何JVM上,而不只是集成到JBoss的应用服务器中;
(2)activemq支持大量的跨语言客户端;
(3)activemq支持许多不同的协议,如Ajax,REST,Stomp,OpenWire,XMPP
(4)activemq支持许多高级功能,例如MessageGroups,ExclusiveConsumer,CompositeDestinations
(5)activemq支持可靠连接并且具有可配置的自动重连接
(6)activemq对有很好的支持
(7)activemq支持跨网络的分布式目的地
(8)activemq是速度非常快;一般要比jbossmq快10倍
(9)群集(Cluster):
为了简化点对点通讯模式中的系统配置,MQ提供Cluster(群集)的解决方案。
群集类似于一个域(Domain),群集内部的队列管理器之间通讯时,不需要两两之间建立消息通道,而是采用群集(Cluster)通道与其它成员通讯,从而大大简化了系统配置。
此外,群集中的队列管理器之间能够自动进行负载均衡,当某一队列管理器出现故障时,其它队列管理器可以接管它的工作,从而大大提高系统的高可靠性。
一、activeMQ主要的几类部署方式比较
1、默认的单机部署(kahadb)
activeMQ的默认存储的单机方式,以本地kahadb文件的方式存储,所以性能指标完全依赖本地磁盘IO,不能提供高可用。
2、基于zookeeper的主从(levelDBMaster/Slave)
因为有实时同步数据的slave的存在,master不用担心数据丢失,所以leveldb会优先采用内存存储消息,异步同步到磁盘。
所以该方式的activeMQ读写性能都最好,特别是写性能能够媲美非持久化消息。
优点:
实现高可用和数据安全
性能较好
缺点:
因为选举机制要超过半数,所以最少需要3台节点,才能实现高可用。
3、基于共享数据库的主从(SharedJDBCMaster/Slave)
可以基于postgres、mysql、oracle等常用数据库。
每个节点启动都会争抢数据库锁,从而保证master的唯一性,其他节点作为备份,一直等待数据库锁的释放。
因为所有消息读写,其实都是数据库操作,activeMQ节点本身压力很小,性能完全取决于数据库性能。
优点:
实现高可用和数据安全
简单灵活,2台节点就可以实现高可用
缺点:
稳定性依赖数据库
性能依赖数据库
实现MQ分布式
一.5.1Master/Slave集群搭建-传统式
Kahadb是activemq从版本5.4之后的默认消息存储引擎
一般activemq的MasterSlave是基于KAHADB的阻塞来做的,先看一下原理
把masterconf目录中的jetty.xml中的端口改成8161
把slaveconf目录中的jetty.xml中的端口改成8162
此时把master和slave先后启动,其实你也可以不用管顺序,谁先启动谁会先把
当master宕机后slave会自动启动转变为master。
当宕掉的master再次被启动后然后变成slave挂载在原先的slave下面变成slave’
一.5.2Master/Slave集群搭建-基于ZooKeeper
ReplicatedLevelDBStore方式
这种主备方式是ActiveMQ5.9以后才新增的特性,使用ZooKeeper协调选择一个node作为master。
被选择的masterbrokernode开启并接受客户端连接。
其他node转入slave模式,连接master并同步他们的存储状态。
slave不接受客户端连接。
所有的存储操作都将被复制到连接至Master的slaves。
如果master死了,得到了最新更新的slave被允许成为master。
failednode能够重新加入到网络中并连接master进入slavemode。
所有需要同步的disk的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。
所以,如果你配置了replicas=3,那么法定大小是(3/2)+1=2.Master将会存储并更新然后等待(2-1)=1个slave存储和更新完成,才汇报success。
至于为什么是2-1,熟悉Zookeeper的应该知道,有一个node要作为观察者存在。
单一个新的master被选中,你需要至少保障一个法定node在线以能够找到拥有最新状态的node。
这个node将会成为新的master。
因此,推荐运行至少3个replicanodes,以防止一个node失败了,服务中断。
从ActiveMQ5.10开始出现了使用ZooKeeper来进行Master/Slave搭建的模式。
搭建时请务必注意下面几个问题:
1.参于masterslave组网的配置中 2.ActiveMQ至少需要3个实例(2N+1公式),只要不符合2N+1,masterslave集群会发生集群崩溃。 搭建ZooKeeper,你可以搭建3个ZooKeeper实例也可以只用1个,如果出于高可用性考虑建议使用3台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+1的ZooKeeper,那你必须依次在data目录下建立2、3两个文件夹并且在每个文件夹下都有一个myid的文件,文件的内容依次也为2,3,然后把下面注释掉的3行server.1server.2server.3前的#注释符放开。 因此data目录下的目录名和myid中的内容对应的就是server.x这个名字。 核心配置 以下是传统的Master/Slave配置 基于ZK的配置(添加基于replicatedLevelDB的持久化配置) 一.5.3Master/Slave集群搭建-BrokerCluster搭建 所谓cluster即负载匀衡,它负载的是“用户”的请求,此处的用户就是调用端 cluster的用法就是用来分散用户的“并发”请求的。 前面説过,ActiveMQ的Cluster有两种: 1动态式(multicast) 2静态式(static) 在实际应用场景中”静态方式“被大量使用,动态式使用的是multicast即组播式,基本已被淘汰。 核心配置 在61616中的配置 在61617中的配置 客户端的配置 一.5.4Master/Slave集群搭建-BrokerCluster和MasterSlave对比 优点 自动分发调用端请求 流量分散 缺点 当调用端连接上任意一个节点发送了一条消息,比如说往NODEA发送了一条消息。 此时消费端还没来得及消费NODEA上的消息该节点就发生宕机了。 此时调用端因为有failover所以它会自动连上另一个节点(NODEB)而该节点上是不存在刚才“发送的消息”的,因为刚才发送到NODEA的消息只在NODEA上,没有同步到NODEB上。 因为只有MasterSlave会做主从间的消息同步,这是一个致命伤。 一.5.5MASTERSLAVE+BROKERCLUSTER的搭建 考虑到消费端可能会发生: 当Group1中有未消费的数据时时,消费端此时被转派到了Group2中的任意一个节点。 master/slave模式下,消息会被逐个复制 而cluster模式下,请求会被自动派发 我们使用ZK搭建MASTERSLAVE 我们使用BROKERCLUSTER把两个“组”合并在一起 先来看下面的集群规划 Group1的配置 由于这涉及到两个组6个ActiveMQ的实例配置,如果把6个配置全写出来是完全没有必要的,因此我就把配置分成两组来写吧。 每个组的配置对于其组内各个节点都为一致的,除去那些个端口号。 Group1的配置(保持6个实例中brokerName全部为一致) 可以看到这边的brokercluster的配置是用来确保每一台都可以和Group2中的各个节点保持同步 Group2的配置 可以看到这边的brokercluster的配置是用来确保每一台都可以和Group1中的各个节点保持同步 一.5.6MASTERSLAVE+BROKERCLUSTER的搭建-客户端 一.5.7MASTERSLAVE+BROKERCLUSTER的搭建-实验 1、先把所有实例进程全部杀掉 2、把6台实例全部启动起来 3、把客户端写上全部6台实例 4、使用生产端任意发送30条消息 5、生产端连上了61616与61619(ctivemqa1、activemqa2),发送了30条消息,61616和61619收到信息,消费端消息进行消费 6、然后我们把61616、61619所属的activemqa1、activemqa2的进程直接杀了 7、然后运行消费端,消费端连上了61617、61619,activemqb1、activemqb2成为master,控台显示无任何消息消费 8、再重启activemqa1、activemqa2,杀掉activemqb1、activemqb2,此时activemqc1、activemqc2成为master,控台显示无任何消息消费 9、ok 实现MQ持久化 一.6MQ持久化配置修改 一.6.1持久化为数据库 在activemq的conf目录下的activemq.xml,找到 把它注释掉换成: 此处是以持久化到oracle为例,因此需要引用把oracle的驱动jar包,并在在activemq.xml的 运行activemq,可以发现自动创建了三张表: 1、activemq_acks 用于存储订阅关系。 如果是持久化Topic,订阅者和服务器的订阅关系在这个表保存。 2、activemq_lock 此表用于主从模式锁定,当第一个activemq服务器启动后会锁住此表成为master,第二个activemq服务器启动后试图锁住此表不会成功,成为slave。 3、activemq_msgs: 此表用于持久化消息,所有需要持久化的消息会记录在此表中,消息的具体内容是BLOB字段。 一.6.2持久化为文件 KahaDB是从ActiveMQ5.4开始默认的持久化插件,也是我们项目现在使用的持久化方式。 KahaDb恢复时间远远小于其前身AMQ并且使用更少的数据文件,所以可以完全代替AMQ。 kahaDB的持久化机制同样是基于日志文件,索引和缓存。 配置方式: directory: 指定持久化消息的存储目录 journalMaxFileLength: 指定保存消息的日志文件大小,具体根据你的实际应用配置 KahaDB主要特性 1、日志形式存储消息; 2、消息索引以B-Tree结构存储,可以快速更新; 3、完全支持JMS事务; 4、支持多种恢复机制; 系统功能MQ集成 一.6.3日志消息的集成 已集成到大宗宝系统,已在使用,有控制开关。 一.6.4邮件信息的集成 可以集成到大宗宝 一.6.5短信信息的集成 可以集成到大宗宝
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- activeMQ 消息 中间件
![提示](https://static.bingdoc.com/images/bang_tan.gif)