ActiveMQ笔记:一个高稳定,可扩展的的部署方案

简介:

本文介绍一个笔者在实际工作中的实施的基于ActiveMQ的一个高稳定,可扩展的异步消息系统。

ActiveMQ是一个成熟的基于Java语言的开源消息系统,在实际应用中被大量使用。ActiveMQ在系统稳定性,系统的容错和扩展等方面都有很多成熟的方案,也有很多开源的管理工具,是部署异步消息系统的一个很好的选择。

ActiveMQ工作机制

ActiveMQ有两种消息使用方式:

l  Queue模式:Producer发出到Queue里的消息,只能由一个Consumer来使用。

l  Topic模式:Producer发送到Topic里的消息,会传送到Subscribe这个Topic的每一个Consumer。

 

Producer发出的消息有两种Delivery模式。

l  Persistent:Broker需要保存消息,然后把消息发送到Consumer。如果Broker崩溃后,重新启动后保存的消息可以重新发送给Consumer。

l  NonPersistent:Broker不需要保存消息,直接把消息发送到Consumer。

 

ActiveMQ可以通过Networks of Brokers方式将多个Broker组成一个Cluster。Producer和Consumer可以任意的连接到该Cluster中的任意一个Broker。Producer发送的消息可以通过Cluser传送到需要的Consumer。

 

ActiveMQ提供了Master Slave机制实现Broker的HA,有以下几种方式:

l  JDBC Master Slave

l  Shared File System Master Slave

l  KahaDB Replication(ZooKeeper experimental)

同一个Broker,只能有一个Master来传送消息。当Master崩溃后,其他的一个Slave可以作为Master。采用HA的模式,会增加系统的复杂性,也会影响系统的性能。

方案

实际部署中,ActiveMQ采用Queue的消息使用模式。Producer发送的消息使用Persistent的Delivery模式。

 

在两个node上部署ActiveMQ的Broker,通过ActiveMQ的Networks of Brokers方式来组成Cluster。

 

系统里的消息应用Instance通过ActiveMQ提供的client类库采用failover TCP的方式随机的接入到ActiveMQ的cluster中。正常情况下,消息应用Instance可以通过ActiveMQ的cluster机制正常通信。如果某个ActiveMQ的node崩溃后,client会自动检测到该情况,切换到另一个ActiveMQ的node。

 

由于本系统只采用Queue的消息工作方式,而且消息的传送采用persistent的模式。如果一个node崩溃后,重新启动后,保存的消息还可以重新发送到Consumer。对Broker,就不采用Master/Slave的HA模式,避免增加系统的复杂性和降低系统的性能。

 

配置

ActiveMQ的Broker的配置如下。

 

#Broker 1:

<!-- The transport connectors ActiveMQ will listen to -->

<transportConnectors>

<transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>

</transportConnectors>

 

<!--

The store and forward broker networks ActiveMQ will listen to.

We'll leave it empty as duplex network will be configured by another broker.

-->

<networkConnectors>

</networkConnectors>

 

#Broker 2:

<!-- The transport connectors ActiveMQ will listen to -->

<transportConnectors>

<transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>

</transportConnectors>

 

<!--

The store and forward broker networks ActiveMQ will listen to

Create a duplex connector to the first broker

-->

<networkConnectors>

<networkConnector uri="static:(tcp://{Broker1Ip}:61616)" duplex="true"/>

</networkConnectors>

目录
相关文章
|
6月前
|
负载均衡 监控 算法
Finagle:构建可靠的分布式系统的利器
今天介绍一个强大的工具,它能够帮助您构建可靠的分布式系统 - **Finagle**。作为一个开源的网络通信框架,Finagle在大规模分布式系统中扮演着至关重要的角色。它以其可扩展性、灵活性和高度可定制的特性而受到广泛赞誉。让我们一起深入了解Finagle,并探索它如何帮助您构建稳健的分布式应用程序。
88 0
|
2月前
|
缓存 负载均衡 监控
从零开始搭建一个高可用的后端架构
【2月更文挑战第6天】本文将介绍如何从零开始搭建一个高可用的后端架构,包括架构设计、技术选型、部署和监控等方面。通过对各种技术的分析和实践,帮助读者深入理解高可用架构的实现和优化。
|
4月前
|
消息中间件 监控 负载均衡
Kafka 最佳实践:构建可靠、高性能的分布式消息系统
Apache Kafka 是一个强大的分布式消息系统,被广泛应用于实时数据流处理和事件驱动架构。为了充分发挥 Kafka 的优势,需要遵循一些最佳实践,确保系统在高负载下稳定运行,数据可靠传递。本文将深入探讨 Kafka 的一些最佳实践,并提供丰富的示例代码,帮助大家更好地应用这一强大的消息系统。
|
4月前
|
消息中间件 监控 安全
Kafka安全性探究:构建可信赖的分布式消息系统
在本文中,将研究Kafka的安全性,探讨如何确保数据在传输和存储过程中的完整性、机密性以及授权访问。通过详实的示例代码,全面讨论Kafka安全性的各个方面,从加密通信到访问控制,帮助大家构建一个可信赖的分布式消息系统。
|
11月前
|
缓存 负载均衡 NoSQL
JD架构师告诉你亿级流量架构高性能、高可用、高扩展如何搭建的?
你们知道淘宝,京东这些购物商场吗?他们到了双11,双12为什么能支持全国14亿人口同时购物下单呢,因为他们的程序做到了高并发、高性能、高可用。那么你对程序员的三高了解多少呢?
|
11月前
|
消息中间件 存储 Kubernetes
干货:分享一个具有高可用性和可伸缩性的ELK架构实战案例
干货:分享一个具有高可用性和可伸缩性的ELK架构实战案例
156 0
|
12月前
|
存储 缓存 NoSQL
高性能的本地缓存方案选型,看这篇就够了!
高性能的本地缓存方案选型,看这篇就够了!
22709 0
|
12月前
|
机器学习/深度学习 人工智能 开发者
阿里云PAI发布基于HLO的全自动分布式系统 TePDist,并宣布开源!
阿里云PAI发布基于HLO的全自动分布式系统 TePDist,并宣布开源!
|
消息中间件 存储 缓存
【Alibaba中间件技术系列】「RocketMQ技术专题」系统服务底层原理以及高性能存储设计分析
【Alibaba中间件技术系列】「RocketMQ技术专题」系统服务底层原理以及高性能存储设计分析
166 0
【Alibaba中间件技术系列】「RocketMQ技术专题」系统服务底层原理以及高性能存储设计分析
|
iOS开发 Windows
弱网环境搭建方案选型
今天来聊聊目前大致有哪些可以搭建弱网环境的方案以及各自存在的问题。
449 0

热门文章

最新文章