中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

說說MQ之RocketMQ(一)

2018-10-16    來源:importnew

容器云強勢上線!快速搭建集群,上萬Linux鏡像隨意使用

RocketMQ 是出自 A 公司的開源產品,用 Java 語言實現(xiàn),在設計時參考了 Kafka,并做出了自己的一些改進,消息可靠性上比 Kafka 更好,目前,RocketMQ 的文檔仍然不夠豐富?1?2,社區(qū)仍然無法與 Kafka 比肩,但 A 公司已經推出了基于 RocketMQ 的云產品?3,相信未來 RocketMQ 也會有不錯的發(fā)展。本文采用 RocketMQ 3.2.6 進行實驗,由于 RocketMQ 與 Kafka 很相似,本文很多地方對兩者做出了比較。

基本概念

RocketMQ 由于借鑒了 Kafka 的設計,包括組件的命名也很多與 Kafka 相似,下面摘抄一段《RocketMQ 原理簡介》中的介紹,可以與 Kafka 的命名比對一下,

  • Producer,消息生產者,負責產生消息,一般由業(yè)務系統(tǒng)負責產生消息。
  • Consumer,消息消費者,負責消費消息,一般是后臺系統(tǒng)負責異步消費。
  • Push Consumer,Consumer 的一種,應用通常向 Consumer 對象注冊一個 Listener 接口,一旦收到消息,Consumer 對象立 刻回調 Listener 接口方法。
  • Pull Consumer,Consumer 的一種,應用通常主動調用 Consumer 的拉消息方法從 Broker 拉消息,主動權由應用控制。
  • Producer Group,一類 Producer 的集合名稱,這類 Producer 通常發(fā)送一類消息,且發(fā)送邏輯一致。
  • Consumer Group,一類 Consumer 的集合名稱,這類 Consumer 通常消費一類消息,且消費邏輯一致。
  • Broker,消息中轉角色,負責存儲消息,轉發(fā)消息,一般也稱為 Server。在 JMS 規(guī)范中稱為 Provider。

《RocketMQ 原理簡介》中還介紹了一些其他的概念,例如,廣播消費和集群消費,廣播消費是 Consumer Group 中對于同一條消息每個 Consumer 都消費,集群消費是 Consumer Group 中對于同一條消息只有一個 Consumer 消費。Kafka 采用的是集群消費,不支持廣播消費(好吧,是我沒有找到)。再例如,普通順序消息和嚴格順序消息,普通順序消息在 Broker 重啟情況下不會保證消息順序性;嚴格順序消息即使在異常情況下也會保證消息的順序性。個人理解,所謂普通順序消息,應該就是 Kafka 中的 Partition 級別有序,嚴格順序消息,應該是 Topic 級別有序,但文中也提到,這樣的有序級別是要付出代價的,Broker 集群中只要有一臺機器不可用,則整個集群都不可用,降低服務可用性。使用這種模式,需要依賴同步雙寫,主備自動切換,但自動切換功能目前還未實現(xiàn)(我猜,自動切換僅僅是沒開源吧)。說白了,嚴格順序消息不具備生產可用性,自己玩玩還行,其應用場景主要是數(shù)據(jù)庫 binlog 同步。

關于 RocketMQ 和 Kafka 的對比,可以參考 RocketMQ Wiki 中的文章?4,看看就行,不必較真。

關于順序和分區(qū)

順序性的話題,剛才已經提到了一些,RocketMQ 的實現(xiàn)應該不弱于 Kafka。對于分區(qū),RocketMQ 似乎有意弱化了這個概念,只有在 Producer 中有一個參數(shù)?defaultTopicQueueNums,分區(qū)在 RocketMQ 中有時被稱為隊列。RocketMQ 的普通順序消息模式,應該就是分區(qū)順序性,這點與 Kafka 一致。

關于高可用

RocketMQ 實現(xiàn)高可用的方式有多種,《RocketMQ 用戶指南》文檔中提到的有:多主模式、多主多從異步復制模式、多主多從同步復制模式。多主模式下,性能較好,但是在 Broker 宕機的時候,該 Broker 上未消費的交易不可消費;多主多從異步復制模式,與 Kafka 的副本模式比較類似,主 Broker 宕機后,會自動切換到從 Broker,消息的消費不會出現(xiàn)間斷;多主多從同步復制模式更進一步,采用同步刷盤的方式,避免了主 Broker 宕機帶來的消息丟失,但是,目前不支持自動切換。

雖然 RocketMQ 提供了多種高可用方式,但是目前能生產使用的就只有多主多從異步復制模式,即使在這個模式上,其實現(xiàn)也比 Kafka 要差。因為 RocketMQ 的機制中,主從關系是人為指定的,主 Broker 上承擔所有的消息派發(fā),而 Kafka 的主從關系是通過選舉的方式選出來的,每個分區(qū)的主節(jié)點都是不一樣的,可以從不同的節(jié)點派發(fā)消息。Kafka 的模式是分散模式,有利于負載均衡,而且當一個 Broker 宕機的時候,只影響部分 Topic,而 RocketMQ 一旦主 Broker 宕機,會影響所有的 Topic。另外,Kafka 可以支持 Broker 間同步復制(通過設置 Broker 的?acks?參數(shù)),這樣比的話,RocketMQ 就差太多了。

關于 RocketMQ 的介紹,網上的文章不算太多,也比較雜,《分布式開放消息系統(tǒng)(RocketMQ)的原理與實踐》5?6?7這篇原理介紹的不錯,推薦。

RocketMQ 的工具和編程接口

RocketMQ 的工具

相比較 Kafka 而言,RocketMQ 提供的工具要少一些,如下,

bin/mqadmin
bin/mqbroker
bin/mqbroker.numanode0
bin/mqbroker.numanode1
bin/mqbroker.numanode2
bin/mqbroker.numanode3
bin/mqfiltersrv
bin/mqnamesrv
bin/mqshutdown

除了進程啟停之外,常用的運維命令都在?mqadmin?中,詳見《RocketMQ 運維指令》文檔。我實驗中常用的一些命令如下,

sh mqnamesrv &
sh mqbroker -c async-broker-a.properties &
sh mqbroker -c async-broker-a-s.properties &
sh mqadmin topicList -n 192.168.232.23:9876
sh mqadmin topicRoute -n 192.168.232.23:9876 -t TopicTestjjj
sh mqadmin clusterList -n 192.168.232.23:9876
sh mqadmin deleteTopic -c DefaultCluster -n 192.168.232.23:9876 -t TopicTestjjj
sh mqadmin consumerProgress -n 192.168.232.23:9876 -g ConsumerGroupNamecc4
sh mqadmin deleteSubGroup -c DefaultCluster -n 192.168.232.23:9876 -g ConsumerGroupNamecc4
sh mqadmin consumerConnection -n 192.168.232.23:9876 -g ConsumerGroupNamecc4

RocketMQ 使用了自己的 name server 來做調度(Kafka 用了 Zookeeper),使用?sh mqnamesrv?來啟動,默認監(jiān)聽端口9876,sh mqnamesrv -m?可以查看所有默認參數(shù),使用?-c xxxx.properties?參數(shù)來指定自定義配置。sh mqbroker?是用于啟動 Broker 的命令,參數(shù)比較多,詳細可以通過?sh mqbroker -m?查看默認參數(shù),配置項細節(jié)后文再說。sh mqadmin?是運維命令入口,topicList?是列出所有 Topic;topicRoute?是列出單個 Topic 的詳細信息;clusterList?是列出集群的信息;deleteTopic?是刪除 Topic。consumerProgress?是查看消費者消費進度,deleteSubGroup?是刪除消費者的訂閱,consumerConnection?是查詢消費者訂閱的情況。

Broker 的配置是最多的,實驗中我修改到的部分如下,其他使用默認,

brokerClusterName=DefaultCluster
brokerIP1=192.168.232.23
brokerName=broker-a
brokerId=0
namesrvAddr=192.168.232.23:9876
listenPort=10911
deleteWhen=04
fileReservedTime=120
storePathRootDir=/home/arnes/alibaba-rocketmq/data/store-a-async
storePathCommitLog=/home/arnes/alibaba-rocketmq/data/store-a-async/commitlog
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

配置文件中的多數(shù)配置看例子就可以知道意思,挑幾個說一下。brokerName?和?brokerId, 同名的 Broker,ID 是0的是主節(jié)點,其他是從節(jié)點;deleteWhen,刪除文件時間點,默認凌晨4點;fileReservedTime,文件保留時間,設置為120小時;brokerRole,Broker 的角色,ASYNC_MASTER 是異步復制主節(jié)點,SYNC_MASTER 是同步雙寫主節(jié)點,SLAVE 是備節(jié)點。

其實,這些工具的寫法也基本一致,都是先做一些檢查,最后運行 Java 程序,JVM 系統(tǒng)上的應用應該差不多都這樣。

  1. https://github.com/alibaba/RocketMQ?
  2. https://github.com/alibaba/RocketMQ-docs?
  3. http://www.aliyun.com/product/ons?
  4. https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka?
  5. http://www.jianshu.com/p/453c6e7ff81c?
  6. http://blog.csdn.net/lovesomnus/article/details/51776942?
  7. http://www.tuicool.com/articles/f2aaUnV?
  8. https://github.com/alibaba/RocketMQ/wiki/filter_server_guide?

標簽: 數(shù)據(jù)庫

版權申明:本站文章部分自網絡,如有侵權,請聯(lián)系:west999com@outlook.com
特別注意:本站所有轉載文章言論不代表本站觀點!
本站所提供的圖片等素材,版權歸原作者所有,如需使用,請與原作者聯(lián)系。

上一篇:[譯] 谷歌團隊的容器運維最佳實踐

下一篇:Kafka Controller Redesign方案