Apache ActiveMQ实战(2)

  • 时间:
  • 浏览:4

若果,朋友把MASTER/SLAVE和BROKER CLUSTER两者相结合,都还可以 得到一有十个 全部处理方案:即又都还可以 做到集群又都还可以 做到任何一有十个 BROKER肯能占据 宕机节点消息若果丢失。

当master宕机后slave会自动启动转变为master。

slave配置(无须忘了改conf目录下的jetty.xml文件中的端口)

哈 哈 ,无须急,再重复一遍该实验,来:

  • 先把所有实例进程全部杀掉
  • 把6台实例全部启动起来(乖乖,好家伙)
  • 把客户端写上全部6台实例(乖乖,好长一陀)
  • 使用生产端任意发送3条消息。
  • 生产端连上了61616,发送了3条消息,若果朋友把61616所属的activemq1的进程直接杀了
  • 若果运行消费端,消费端连上了61620,控台显示无任何消息消费

肯能,你设的是duplex=true,它大概 下面几行的效果:

master slave一旦启动后,在客户端的配置就很简单了,如下:

Group1中的配置

朋友来看,肯能朋友把有十个 group间都还可以 打通,是都有就都还可以 在上述清况 占据 时做到failover到group2上时并能消费掉group1中的消息了呢?

为什么我么我做?很简单,未必若果一有十个 参数

Shared File System Master Slave

肯能你使用共享文件系统,没得一些你使用Shared File System Master Slave。如下图所示:

在任何清况 下朋友都应该先尝试连接master,故在客户端朋友曾经 配置: 

这边还有一有十个 replicas=“3”的设置 ,这边的数字指的若果ActiveMQ实例的节点数,它前要满足2N+1,若果你也都还可以 5台(1拖4)。

客户端调用:

优点



客户端使用failover Transport 去连接 broker,类式:                                                            

若果,在配置时前要进行如下的穿透:

<kahaDB directory=“/localhost/kahadb”/>

中的db lock住,它就成了mater,而此时曾经 实例会占据 “pending”清况 。

对于上述清况 ,当61616宕机后,肯能此时请求被failover到了group1中任意一有十个 节点时,此时消费端全部都还可以 拿到肯能宕机而未被消费掉的消费。

现在知道为哪有几个要duplex=true了吧!



Group2中的配置

Group2中的每一有十个 节点都有再前要来一句以下曾经 的东西了:

  • MASTER/SLAVE模式
  • Cluster模式

Pure Master Slave



Pure master slave的工作法律土办法:

若果,上述清况 是用于应对百万级并发消息的生产环境而言才前要没得大动干戈,对于常规环境笔者建议:

肯能这涉及到有十个 组6个ActiveMQ的实例配置,肯能把6个配置全写出来是全部没得必要的,若果一些你把配置分成两组来写吧。每个组的配置对于其组内各个节点都为一致的,除去哪有几个个端口号。Group1的配置(保持6个实例中brokerName全部为一致)

当调用端连接上任意一有十个 节点发送了十根消息,比如说往NODE A发送了十根消息。

请维持各cluste节点间不同的持久化法律土办法(你也都还可以 使用kahadb,但无须做成和master slave一样的排它锁法律土办法啊。

<beans> 
<broker xmlns="http://activemq.org/config/1.0" brokerName="JdbcMasterBroker"> 
<persistenceAdapter> 
<jdbcPersistenceAdapter dataSource="#mysql-ds"/> 
</persistenceAdapter> 
</broker> 
<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
<property name="driverClassName" value="com.mysql.jdbc.Driver"/> 
<property name="url" value="jdbc:mysql://localhost:35006/test?relaxAutoCommit=true"/> 
<property name="username" value="username"/> 
<property name="password" value="passward"/> 
<property name="poolPreparedStatements" value="true"/> 
</bean> 
</beans> 

下面给出核心配置:

master配置(无须忘了改conf目录下的jetty.xml文件中的端口)

其中/sharedFileSystem是文件共享的系统文件目录



都还可以 看一遍这边的broker cluster的配置是用来确保每一台都都还可以 和Group1中的各个节点保持同步

  • 生产和消费分成有十个 进程。
  • 生产发十根消息,注意看console会输出如“[INFO] Successfully reconnected to tcp://192.168.0.101:61616”
  • 手工停止61616这台实例,若果一些你发觉61617肯能 是61618暗含一台被promoted to master
  • 若果运行consumer,consumer会连上被promoted的实例并继续消费刚才那3条消息
是为。。。high available。

网上所有教程都没得说明一些zkPath到底是一有十个 哪有几个东西,害得一堆的使用者以为这是一有十个 目录,以为用ZK做mq的集群也前要“共享”一块磁盘空间。



此时消费端还没来得及消费NODE A上的消息该节点就占据 宕机了。此时调用端肯能有failover很多它会自动连上曾经 节点(NODE B)而该节点上是不占据 刚才“发送的消息”的,肯能刚才发送到NODE A的消息只在NODE A上,没得同步到NODE B上。

肯都里还可以Master Slave会做主从间的消息同步,这是一有十个 致命伤。

把6台实例全部启动起来(乖乖,好家伙)

把客户端写上全部6台实例(乖乖,好长一陀)

哈 哈 ,死惨了。。。作者滚粗。。。



搭个集群,前要共享磁盘???见了鬼去了,一些方案肯定都有最好的!

若果,从ActiveMQ5.10开始突然出现了使用ZooKeeper来进行Master/Slave搭建的模式。

比如说,我有十个 节点,其中生产连着A和B,消费连着C、D、E,若果在A上对C、D、E做穿透,B也对C、D、E做穿透,客户端只对A和B做failover,这就构成了一有十个 spoker机制。它也都还可以 制作出一有十个 MASTER SLAVE + Broker Cluster的模型来,若果producer对a,b进行监听,而consumer failerover至c,d,e即可,一些架构没能,动一下手就会了。

MASTER SLAVE+BROKER CLUSTER的搭建-客户端

客户端:

JDBC Master Slave的工作原理跟Shared File System Master Slave类式,若果采用了数据库作为持久化存储

为哪有几个 ?WHY?

所谓的完美方案并都有真正的完美方案-清况 A

是的,以上的方案占据 着一些漏洞!来看原理!

朋友知道:

按照2N+1,你前要大概 建立十个 ActiveMQ实例。在搭建前朋友先来看一下朋友的集群规划吧

没得可不都还可以 把两者集成起来呢?答案是有的,网上所谓的独创。。。很多是错的!!对,肯能我全试验过了我敢没得説,写得都一些个啥呀。。。一有十个 个还COPY不走样,全错了若果。

静态网络代理



Static:(uri1,uri2,uri3,…)?key=value 或是Failover:(uri1, … , uriN)?key=value

  • Master slave 
  • Broker clusters
ActiveMQ的集群有這個 法律土办法:

考虑到消费端肯能会占据 :

当Group1暗含未消费的数据时时,消费端此时被转派到了Group2中的任意一有十个 节点。



无须忘了,十个 MQ实例的brokerName前要一致,要不然一些你在集群启动时突然出现:



Broker clusters ,网络型中介(network of brokers)

连接到网络代理的這個 法律土办法:



对于上述清况 ,当61616宕机后,肯能此时请求被failover到了group2中任意一有十个 节点时,此时肯能group2中并未保存group1中的任何消息,若果若果你的请求被转发到曾经 group中,消费端是决无肯能去消费本不占据 的消息的。这都有有肯能若果一定会占据 的清况 。肯能在生产环境中,请求是会被自由随机的埋点给不同的节点的。

我为哪有几个要提一些缺点、要提前大选曾经 的篇章? 我若果为了让朋友感受一下网上COPYqq克隆好友 还是错误信息的博文的严重性,那。。。为什么我么我做是真正完美的方案呢。。。



内嵌代理所引发的哪有几个的问题图片:

都还可以 看一遍这边的broker cluster的配置是用来确保每一台都都还可以 和Group2中的各个节点保持同步



肯能在集群启动后当master宕机slave被promote成master时占据 集群崩溃。

  • 生产端连上了61616,发送了3条消息,若果朋友把61616所属的activemq1的进程直接杀了
  • 若果运行消费端,消费端连上了61618,消费成功3条消息
学会英语了!

下面来看用“穿透机制”改造的真正完美方案吧。

怎样才能处理哪有几个哪有几个的问题图片——集群的這個 法律土办法:

搭建时请务必注意下面有几个哪有几个的问题图片:

本例中,朋友只使用一有十个 ZK节点,即2181端口来做MQ1-3的数据文件共享。



cluster的用法若果用来分散用户的“并发”请求的。前面説过,ActiveMQ的Cluster有這個 :

按照一些思路朋友在各Group中的各节点中作如下配置即可:

依次把3台mq实例均配置成replicatedLevelDB即可,在此配置暗含一有十个 zkPath,笔者使用的是默认配置。你也都还可以 自行去掉 如:

在ZK的data目录下建立一有十个 目录,名为“1”,并在其下建立一有十个 文件,文件名为“myid”并使其内容为1

具体实验步骤:

我一些才叫独创,来看原理。

Not enough cluster members when using LevelDB replication曾经 的错误。

客户端的配置

<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
	<property name=“brokerURL” value=“failover:(tcp://192.168.0.101:61616,tcp://192.168.0.101:61617)" />
	 <property name="useAsyncSend" value="true" />
	 <property name="alwaysSessionAsync" value="true" />
	 <property name="useDedicatedTaskRunner" value="false" />
</bean>



所谓cluster即负载匀衡,它负载的是“用户”的请求,此处的用户若果调用端



在实际应用场景中”静态法律土办法“被血块使用,动态式使用的是multicast即组播式,基本肯能被淘汰,若果朋友主要基于静态法律土办法来做cluster讲解。

  • 把master conf 目录中的jetty.xml中的端口改成8161
  • 把slave conf 目录中的jetty.xml中的端口改成8162
此时把master和slave先后启动,未必你也都还可以 我很多 管顺序,谁先启动谁会先把



一般activemq的Master Slave是基于KAHADB的阻塞来做的,先看一下原理



下面给出一有十个 配置实例:

哪有几个叫duplex=true?

它若果用于mq节点间双向传输用的一有十个 功能,看下面的例子



当master broker失效的曾经 。Slave broker 做出了這個 不同的相应法律土办法

肯能你前要在本地搭建2N+1的ZooKeeper,那你前要依次在data目录下建立2、3有十个 文件夹若果在每个文件夹下都有一有十个 myid的文件,文件的内容依次也为2,3,若果把下面注释掉的3行server.1 server.2 server.3前的#注释符放开。

若果data目录下的目录名和myid中的内容对应的若果server.x一些名字。

搭建ZooKeeper,一些你搭建十个 ZooKeeper实例也都还可以 只用一有十个 ,肯能出于高可用性考虑建议使用3台ZooKeeper。

下载ZK,朋友在这边使用的是“zookeeper-3.4.6”,把它解压到Linux服务器上,在其conf目录下生成zoo1.cfg文件 ,内容如下:

核心配置



在61616中的配置

基于ZK的配置

验证

  1. 先把所有实例进程全部杀掉
  2. 把6台实例全部启动起来(乖乖,好家伙)
  3. 把客户端写上全部6台实例(乖乖,好长一陀)
  4. 使用生产端任意发送3条消息。
  5. 生产端连上了61619(属于Group2),发送了3条消息,若果朋友把61619所属的activemq4的进程直接杀了
  6. 若果运行消费端,消费端连上了61616,控台显示消费成功3条消息
大功告成!!!

从生产环境的高可用性来説,肯能前要使用完美处理方案励志的话 朋友大概 前要以下哪有几个实体机



2台实体机

一些你没得实验:

还有這個 集群法律土办法留给朋友被委托人去练习,很简单,若果有几个节点间无MASTER SLAVE也只做static Broker Cluster, 用的若果一些“穿透原理”。

Pure Master Slave具有以下限制:

一些zkPath代表zookeeper内的“路径”,即你运行在2181端口的zk内的“寻址节点”,类式于JNDI。肯能你没得一些zkPath,默认它在zk内的寻址节点为“/default”。加入到某一组master slave中的mq的实例中的zkPath前要全部匹配。

  • 每台虚出十个 子节点来(用VM),供十个 ZK 节点使用,2*3共为6个
  • 若果一台实体机前要承载一有十个 ZK GROUP,同一有十个 ZK GROUP最好无须跨实体机或虚拟
同一台实体机上不得又安装ZK又安装MQ上述是ActiveMQ Master Slave + Broker Cluster的最小化配置,为了得到更高的高可用性,建议6个MQ实例间全部前要有物理机承载。

核心配置

以下是传统的Master/Slave配置

搞两台高配置的VM分散在两台不同的实体机,做MASTER SLAVE即可,当然笔者强烈建议使用ZK做ActiveMQ的Master Slave,ZK都还可以 用十个 节点,分别来自十个 不同的虚机(都有占据 一有十个 VM里启十个 不同端口的ZK实例,若果来自于3台虚机),至于3台虚机是否在不同实体机上,这倒都有很多要求,肯能在MASTER SLAVE中的ZK只作节点信息、消息同步使用,我很多 受很多并发访问之苦。

先来看下面的集群规划

此时客户肯能连的是节点2,也都还可以 消息节点1中的消息,若果我给它起了一有十个 比英译中更有现实意义的名称我管它叫“穿透”。

注意红色加粗的地方,这是传统的Master Slave的一有十个 过高 。曾经 做太不安全了!

这若果duplex的使用法律土办法,我很奇怪,竟然没得多人COPY 那错的1-2篇博文,若果若果没得提一些duplex的值,若果都设的是false。

duplex的作用若果mq节点1收到消息一定会变成一有十个 sender把消息发给节点2。

几种集群对比

  • broker的集群在多个broker曾经 fail-over和 load-balance,master-slave能fail-over,若果不都还可以load- balance
  • 消息在多个broker之间转发,若果消息只存储在一有十个 broker上,一旦失效前要重启,而主从法律土办法master失效,slave实时备份消息。
  • jdbc法律土办法成本高,强度低
  • master-slave法律土办法中pure法律土办法管理起来麻烦