activeMQ消息中間件

1、 消息中間件分布式說明書 第 一 章 中間件選型1.1 KafkaKafka是linkedin開源的MQ系統(tǒng)，主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，0.8開始支持復(fù)制，不支持事務(wù)，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。1.2 RabbitMQRabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業(yè)級的開發(fā)。結(jié)合erlang語言本身的并發(fā)優(yōu)勢，性能較好，但是不利于做二次開發(fā)和維護(hù)。1.3 RocketMQ 阿里巴巴的MQ中間件，

2、在其多個產(chǎn)品下使用，并能夠撐住雙十一的大流量，他并沒有實現(xiàn)JMS規(guī)范，使用起來很簡單。部署由一個 命名服務(wù)（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支持集群，隊列的容量受機器硬盤的限制，隊列滿后可以支持持久化到硬盤（也可以自己適配代碼，將其持久化到NOSQL數(shù)據(jù)庫中），隊列滿后會影響吞吐量，可以采用主備來保證穩(wěn)定性，支持回溯消費，可以在broker端進(jìn)行消息過濾.1.4 ActiveMQActiveMQ是Apache下的一個子項目。歷史悠久的開源項目，已經(jīng)在很多產(chǎn)品中得到應(yīng)用，實現(xiàn)了JMS1.1規(guī)范，可以和spring-jm

3、s輕松融合，實現(xiàn)了多種協(xié)議，如Ajax，REST，Stomp等，支持持久化到數(shù)據(jù)庫，少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景， 可以很好的運行在任何JVM上，而不只是集成到JBoss的應(yīng)用服務(wù)器中，對spring有很好的支持，支持大量的跨語言客戶端。1.5 ZeroMQZeroMQ號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對這MQ能夠應(yīng)用成功的挑戰(zhàn)。擴展性好，開發(fā)比較靈活，采用C語言實現(xiàn)，實際上他只是一個socket庫的重新封裝，如果我們做為消息隊列使用，需要開發(fā)大量的代碼。Ac

4、tiveMQ消息中間件的選擇從以下方面進(jìn)行考慮：（1）activemq可以很好的運行在任何JVM上，而不只是集成到JBoss的應(yīng)用服務(wù)器中；（2）activemq支持大量的跨語言客戶端；（3）activemq支持許多不同的協(xié)議，如Ajax，REST，Stomp，OpenWire，XMPP（4）activemq支持許多高級功能，例如MessageGroups，ExclusiveConsumer，CompositeDestinations（5）activemq支持可靠連接并且具有可配置的自動重連接（6）activemq對spring有很好的支持（7）activemq支持跨網(wǎng)絡(luò)的分布式目的地（8）a

5、ctivemq是速度非?？?；一般要比jbossmq快10倍（9）群集(Cluster)：為了簡化點對點通訊模式中的系統(tǒng)配置，MQ提供Cluster(群集)的解決方案。群集類似于一個域(Domain)，群集內(nèi)部的隊列管理器之間通訊時，不需要兩兩之間建立消息通道，而是采用群集(Cluster)通道與其它成員通訊，從而大大簡化了系統(tǒng)配置。此外，群集中的隊列管理器之間能夠自動進(jìn)行負(fù)載均衡，當(dāng)某一隊列管理器出現(xiàn)故障時，其它隊列管理器可以接管它的工作，從而大大提高系統(tǒng)的高可靠性。 一、activeMQ主要的幾類部署方式比較1、默認(rèn)的單機部署（kahadb）activeMQ的默認(rèn)存儲的單機方式，以本地kah

6、adb文件的方式存儲，所以性能指標(biāo)完全依賴本地磁盤IO，不能提供高可用。 2、基于zookeeper的主從（levelDB Master/Slave）5.9.0新推出的主從實現(xiàn)，基于zookeeper來選舉出一個master，其他節(jié)點自動作為slave實時同步消息。因為有實時同步數(shù)據(jù)的slave的存在，master不用擔(dān)心數(shù)據(jù)丟失，所以leveldb會優(yōu)先采用內(nèi)存存儲消息，異步同步到磁盤。所以該方式的activeMQ讀寫性能都最好，特別是寫性能能夠媲美非持久化消息。優(yōu)點：實現(xiàn)高可用和數(shù)據(jù)安全性能較好缺點：因為選舉機制要超過半數(shù)，所以最少需要3臺節(jié)點，才能實現(xiàn)高可用。 3、基于共享數(shù)據(jù)庫的主從（

7、Shared JDBC Master/Slave）可以基于postgres、mysql、oracle等常用數(shù)據(jù)庫。每個節(jié)點啟動都會爭搶數(shù)據(jù)庫鎖，從而保證master的唯一性，其他節(jié)點作為備份，一直等待數(shù)據(jù)庫鎖的釋放。因為所有消息讀寫，其實都是數(shù)據(jù)庫操作，activeMQ節(jié)點本身壓力很小，性能完全取決于數(shù)據(jù)庫性能。優(yōu)點：實現(xiàn)高可用和數(shù)據(jù)安全簡單靈活，2臺節(jié)點就可以實現(xiàn)高可用缺點：穩(wěn)定性依賴數(shù)據(jù)庫性能依賴數(shù)據(jù)庫 第 二 章 實現(xiàn)MQ分布式2.1.1 Master/Slave集群搭建-傳統(tǒng)式 Kahadb是activemq從版本5.4之后的默認(rèn)消息存儲引擎一般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”狀態(tài)。當(dāng)master宕機后slave會自動啟動轉(zhuǎn)變?yōu)閙aster。當(dāng)宕掉的master再次被啟動后然后變成slave掛載在原先的sl

9、ave下面變成slave2.1.2 Master/Slave集群搭建-基于ZooKeeperReplicated LevelDB Store方式 這種主備方式是ActiveMQ5.9以后才新增的特性，使用ZooKeeper協(xié)調(diào)選擇一個node作為master。被選擇的master broker node開啟并接受客戶端連接。其他node轉(zhuǎn)入slave模式，連接master并同步他們的存儲狀態(tài)。slave不接受客戶端連接。所有的存儲操作都將被復(fù)制到連接至Master的slaves。如果master死了，得到了最新更新的slave被允許成為master。failed node能夠重新加入到網(wǎng)絡(luò)中并

10、連接master進(jìn)入slave mode。所有需要同步的disk的消息操作都將等待存儲狀態(tài)被復(fù)制到其他法定節(jié)點的操作完成才能完成。所以，如果你配置了replicas=3，那么法定大小是(3/2)+1=2. Master將會存儲并更新然后等待 (2-1)=1個slave存儲和更新完成，才匯報success。至于為什么是2-1，熟悉Zookeeper的應(yīng)該知道，有一個node要作為觀察者存在。單一個新的master被選中，你需要至少保障一個法定node在線以能夠找到擁有最新狀態(tài)的node。這個node將會成為新的master。因此，推薦運行至少3個replica nodes，以防止一個node失敗

11、了，服務(wù)中斷。 從ActiveMQ5.10開始出現(xiàn)了使用ZooKeeper來進(jìn)行Master/Slave搭建的模式。 搭建時請務(wù)必注意下面幾個問題：1 參于master slave組網(wǎng)的配置中<broker xmlns=“/schema/core” brokerName=“zk_cluster_nodes“必須一至。2 ActiveMQ至少需要3個實例（2N+1公式），只要不符合2N+1，master slave集群會發(fā)生集群崩潰。 搭建ZooKeeper，你可以搭建3個ZooKeeper實例也可以只用1個，如果出于高可用性考慮建議使用3

12、臺ZooKeeper。 下載ZK，我們在這邊使用的是“zookeeper-3.4.6”，把它解壓到服務(wù)器上，在其conf目錄下生成zoo1.cfg文件 ，內(nèi)容如下： 在ZK的data目錄下建立一個目錄，名為“1”，并在其下建立一個文件，文件名為“myid”并使其內(nèi)容為1 以server.A=B:C:D的形式指定三臺服務(wù)器 A - 數(shù)字，表示服務(wù)器的編號 B - 服務(wù)器的ip C - 服務(wù)器與集群中的Leader服務(wù)器交換信息的端口 D - 用來執(zhí)行選舉時服務(wù)器相互通信的端口（萬一集群中的 Leader 服務(wù)器掛了，需要一個端口來重新進(jìn)行選舉，選出一個新的 Leade 如果你需要在本地搭建2N+

13、1的ZooKeeper，那你必須依次在data目錄下建立2、3兩個文件夾并且在每個文件夾下都有一個myid的文件，文件的內(nèi)容依次也為2，3，然后把下面注釋掉的3行server.1 server.2 server.3前的#注釋符放開。因此data目錄下的目錄名和myid中的內(nèi)容對應(yīng)的就是server.x這個名字。ü 核心配置以下是傳統(tǒng)的Master/Slave配置ü 基于ZK的配置（添加基于replicatedLevelDB的持久化配置）2.1.3 Master/Slave集群搭建-Broker Cluster搭建所謂cluster即負(fù)載勻衡，它負(fù)載的是“用戶”的請求，此處的

14、用戶就是調(diào)用端cluster的用法就是用來分散用戶的“并發(fā)”請求的。前面説過，ActiveMQ的Cluster有兩種：1 動態(tài)式(multicast）2 靜態(tài)式（static）在實際應(yīng)用場景中”靜態(tài)方式“被大量使用，動態(tài)式使用的是multicast即組播式，基本已被淘汰。ü 核心配置ü 在61616中的配置ü 在61617中的配置ü 客戶端的配置2.1.4 Master/Slave集群搭建-Broker Cluster和Master Slave對比優(yōu)點· 自動分發(fā)調(diào)用端請求· 流量分散缺點當(dāng)調(diào)用端連接上任意一個節(jié)點發(fā)送了一條消息，比如

15、說往NODE A發(fā)送了一條消息。此時消費端還沒來得及消費NODE A上的消息該節(jié)點就發(fā)生宕機了。此時調(diào)用端因為有failover所以它會自動連上另一個節(jié)點（NODE B）而該節(jié)點上是不存在剛才“發(fā)送的消息”的，因為剛才發(fā)送到NODE A的消息只在NODE A上，沒有同步到NODE B上。因為只有Master Slave會做主從間的消息同步，這是一個致命傷。2.1.5 MASTER SLAVE+BROKER CLUSTER的搭建 考慮到消費端可能會發(fā)生：當(dāng)Group1中有未消費的數(shù)據(jù)時時，消費端此時被轉(zhuǎn)派到了Group2中的任意一個節(jié)點。l master/slave模式下，消息會被逐個復(fù)制l 而

16、cluster模式下，請求會被自動派發(fā)l 我們使用ZK搭建MASTER SLAVEl 我們使用BROKER CLUSTER把兩個“組”合并在一起先來看下面的集群規(guī)劃Ø Group1的配置由于這涉及到兩個組6個ActiveMQ的實例配置，如果把6個配置全寫出來是完全沒有必要的，因此我就把配置分成兩組來寫吧。每個組的配置對于其組內(nèi)各個節(jié)點都為一致的，除去那些個端口號。Group1的配置（保持6個實例中brokerName全部為一致）可以看到這邊的broker cluster的配置是用來確保每一臺都可以和Group2中的各個節(jié)點保持同步Ø Group2的配置 可以看到這邊的bro

17、ker cluster的配置是用來確保每一臺都可以和Group1中的各個節(jié)點保持同步2.1.6 MASTER SLAVE+BROKER CLUSTER的搭建-客戶端2.1.7 MASTER SLAVE+BROKER CLUSTER的搭建-實驗1、先把所有實例進(jìn)程全部殺掉2、把6臺實例全部啟動起來3、把客戶端寫上全部6臺實例4、使用生產(chǎn)端任意發(fā)送30條消息5、生產(chǎn)端連上了61616與61619（ctivemqa1、activemqa2），發(fā)送了30條消息，61616和61619收到信息，消費端消息進(jìn)行消費6、然后我們把61616、61619所屬的activemqa1、activemqa2的進(jìn)程直

18、接殺了7、然后運行消費端，消費端連上了61617、61619，activemqb1、activemqb2成為master，控臺顯示無任何消息消費8、再重啟activemqa1、activemqa2，殺掉activemqb1、activemqb2，此時activemqc1、activemqc2成為master，控臺顯示無任何消息消費9、ok第 三 章 實現(xiàn)MQ持久化3.1 MQ持久化配置修改3.1.1 持久化為數(shù)據(jù)庫 在activemq的conf目錄下的activemq.xml，找到 <persistenceAdapter> <kahaDB directory="$a

19、ctivemq.base/data/kahadb"/> </persistenceAdapter> 把它注釋掉換成： <persistenceAdapter> <jdbcPersistenceAdapter dataSource="#oracle-ds"/> </persistenceAdapter> 此處是以持久化到oracle為例，因此需要引用把oracle的驅(qū)動jar包，并在在activemq.xml的 <bean></beans>里面增加數(shù)據(jù)庫的配置，如下： 運行activemq，可以發(fā)現(xiàn)自動創(chuàng)建了三張表： 1、activemq_acks用于存儲訂閱關(guān)系。如果是持久化Topic，訂閱者和服務(wù)器的訂閱關(guān)系在這個表保存。 2、activemq_lock此表用于主從模式鎖定，當(dāng)?shù)谝粋€activemq服務(wù)器啟動后會鎖住此表成為master，第二