rabbitmq升级版本rabbitmq版本选择._股票知识

很多朋友对于rabbitmq升级版本和rabbitmq版本选择不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

本文目录

RabbitMQ 的4种集群架构RabbitMQ与redis的区别是什么呢RabbitMQ集群在linux下安装rabbitmq失败怎么解决RabbitMQ 的4种集群架构也称为Warren(兔子窝)模式。实现rabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模式非常的好用且简单。

也就是一个主/备方案，主节点提供读写，备用节点不提供读写。如果主节点挂了，就切换到备用节点，原来的备用节点升级为主节点提供读写服务，当原来的主节点恢复运行后，原来的主节点就变成备用节点，和activeMQ利用zookeeper做主/备一样，也可以一主多备。

HaProxy配置:

listenrabbitmq_cluster

bind0.0.0.0:567 #配置tcp模式

modetcp #简单的轮询

balanceroundrobin #主节点 roundrobin 随机

server你的76机器hostname 192.168.11.76:5672checkinter5000rise2fall2

server你的77机器hostname 192.168.11.77:5672backupcheckinter5000rise2fall2 #备用节点

注意了，上面的rabbitMQ集群节点配置#inter每隔5秒对mq集群做健康检查，2次正确证明服务可用，2次失败证明服务器不可用，并且配置主备机制

远程模式可以实现双活的一种模式，简称shovel模式，所谓的shovel就是把消息进行不同数据中心的复制工作，可以跨地域的让两个MQ集群互联，远距离通信和复制。

Shovel就是我们可以把消息进行数据中心的复制工作，我们可以跨地域的让两个MQ集群互联。

如图所示，有两个异地的MQ集群（可以是更多的集群），当用户在地区1这里下单了，系统发消息到1区的MQ服务器，发现MQ服务已超过设定的阈值，负载过高，这条消息就会被转到地区2的MQ服务器上，由2区的去执行后面的业务逻辑，相当于分摊我们的服务压力。

在使用了shovel插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性。

如上图所示，当我们的消息到达exchange，它会判断当前的负载情况以及设定的阈值，如果负载不高就把消息放到我们正常的warehouse_goleta队列中，如果负载过高了，就会放到backup_orders队列中。backup_orders队列通过shovel插件与另外的MQ集群进行同步数据，把消息发到第二个MQ集群上。

这是rabbitMQ比较早期的架构模型了，现在很少使用了。

shovel集群的配置，首先启动rabbitmq插件，命令如下:

rabbitmq-pluginsenableamqp_client

rabbitmq-pluginsenable rabbitmq_shovel

在/etc/rabbitmq/目录下创建rabbitmq.config文件。注意，我们源服务器和目的地服务器都使用这个相同的配置文件。

具体配置如下

非常经典的mirror镜像模式，保证100%数据不丢失。在实际工作中也是用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。

mirror镜像队列，目的是为了保证rabbitMQ数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是2-3个节点实现数据同步。对于100%数据可靠性解决方案，一般是采用3个节点。

集群架构如下

如上图所示，用KeepAlived做了HA-Proxy的高可用，然后有3个节点的MQ服务，消息发送到主节点上，主节点通过mirror队列把数据同步到其他的MQ节点，这样来实现其高可靠。

也是实现异地数据复制的主流模式，因为shovel模式配置比较复杂，所以一般来说，实现异地集群的都是采用这种双活或者多活模型来实现的。这种模式需要依赖rabbitMQ的federation插件，可以实现持续的，可靠的AMQP数据通信，多活模式在实际配置与应用非常的简单。

rabbitMQ部署架构采用双中心模式(多中心)，那么在两套(或多套)数据中心各部署一套rabbitMQ集群，各中心的rabbitMQ服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。

多活集群架构如下:

federation插件是一个不需要构建cluster，而在brokers之间传输消息的高性能插件，federation插件可以在brokers或者cluster之间传输消息，连接的双方可以使用不同的users和virtualhosts，双方也可以使用不同版本的rabbitMQ和erlang。federation插件使用AMQP协议通信，可以接受不连续的传输。federation不是建立在集群上的，而是建立在单个节点上的，如图上黄色的rabbitnode3可以与绿色的node1、node2、node3中的任意一个利用federation插件进行数据同步。

如上图所示，federationexchanges可以看成downstream从upstream主动拉取消息，但是并不是拉取所有消息，必须是在downstream上已经明确定义Bingdings关系的exchange，也就是有实际的物理queue来接收消息，才会从upstream拉取消息到downstream。

它使用AMQP协议实现代理间通信，downstream会将绑定关系组合在一起，绑定/解绑命令将发送到upstream交换机。因此，federationexchange只接收具有订阅的消息。

RabbitMQ与redis的区别是什么呢首先说RabbitMQ，RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP,SMTP,STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

其次是Redis，Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

3.3ZeroMQ

ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。

3.4ActiveMQ

ActiveMQ是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。

3.5Kafka/Jafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。ApacheKafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。

如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

RabbitMQ集群如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。

如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。

RabbitMQ集群是一个或多个节点的逻辑分组，每个节点共享用户、虚拟主机、队列、交换器、绑定、运行时参数和其他分布式状态。

一些分布式系统有leader和follower节点。对于RabbitMQ来说，RabbitMQ集群中的所有节点都是平等的。

RabbitMQ集群可以通过多种方式组成：

RabbitMQ节点绑定到端口以接受客户端和CLI工具连接。其他进程和工具（例如SELinux）可能会阻止RabbitMQ绑定到端口。发生这种情况时，节点将无法启动。

CLI工具、客户端库和RabbitMQ节点也会打开连接（客户端TCP套接字）。防火墙会阻止节点和CLI工具相互通信。确保可以访问以下端口：

RabbitMQ节点和CLI工具（例如rabbitmqctl）使用cookie来确定它们是否被允许相互通信。为了让两个节点能够通信，它们必须具有相同的共享密钥，称为Erlangcookie。cookie只是一串最多255个字符的字母数字字符。它通常存储在本地文件中。该文件必须只能由所有者访问（例如具有600或类似的UNIX权限）。每个集群节点必须具有相同的cookie。

在UNIX系统上，cookie通常是位于/var/lib/rabbitmq/.erlang.cookie（由服务器使用）和$HOME/.erlang.cookie（由CLI工具使用）。

RabbitMQ节点使用主机名相互寻址

<!==所有主机执行==>

默认配置文件/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.17/ebin/rabbit.app

<!==node01主机执行==>

<!==node02主机执行==>

<!==node03主机执行==>

<!==所有主机执行==>

因RabbitMQ集群元数据同步基于cookie共享方案实现

文件路径/var/lib/rabbitmq/.erlang.cookie

<!==node02、node03主机执行==>

<!==任意主机执行==>

节点分为：磁盘节点及内存节点

RAM节点是一种特殊情况，可用于提高具有高队列、交换或绑定搅动的集群的性能。RAM节点不提供更高的消息速率。官方建议在绝大多数情况下，仅使用磁盘节点。

如果一个集群中都是RAM节点，那么集群停止，将无法再次启动，并将丢失所有数据

官方提示：经典队列镜像将在未来版本中删除，考虑改用仲裁队列或非复制经典队列

每个镜像队列由一个领导副本和一个或多个镜像副本，leader被托管的节点成为leader节点。首先应用给定队列的所有操作在队列的leader节点上，然后传播到镜像。

如果承载队列的leader节点出现故障，则只要已同步，最旧的镜像将升级为新的leader。根据队列镜像参数，也可以升级未同步的镜像。

队列通过策略启用了镜像，策略模式的说明如下：

每当队列的策略发生变化时，它都保持其现有的镜像尽可能适用新策略。

设置的镜像队列可以通过开启的网页的管理端Admin->Policies，也可以通过命令。

管理端界面：

命令行：

为避免集群中的某个节点托管大多数leader队列，因此导致高负载，leader队列应合理均匀的分布在集群节点上。控制leader队列分布节点策略有三种，可以在rabbitmq.conf文件中定义queue_master_locator参数设置

修改节点策略可能会导致现有的leader队列没有在新的策略中，为了防止消息丢失，RabbitMQ会保留现有的leader直到至少另一个镜像已同步，一旦发生同步，消费者将与leader断开连接，需要重新连接。

如果leader故障，其他镜像升级为leader过程如下：

如果消费者使用自动确认模式，那么消息可能会丢失。这与非镜像队列没有什么不同：代理认为消息一旦以自动确认模式发送给消费者，就会被确认。

如果客户端突然断开连接，则可能永远不会收到消息。在镜像队列的情况下，如果leader死亡，那些正在以自动确认模式发送给消费者的消息可能永远不会被这些客户端接收，并且不会被新leader重新排队。由于消费客户端连接到存活节点的可能性，消费者取消通知有助于识别此类事件何时发生。当然，在实践中，如果数据安全性不如吞吐量重要，那么自动确认模式是可行的方法。

节点可以随时加入集群。根据队列的配置，当节点加入集群时，队列可能会在新节点上添加镜像。此时，新镜像将是空的：它不会包含队列中任何现有的内容。这样的镜像将接收发布到队列的新消息，因此随着时间的推移将准确地表示镜像队列的尾部。随着消息从镜像队列中排出，新镜像丢失消息的队列头部的大小将缩小，直到最终镜像的内容与leader的内容完全匹配。在这一点上，镜像可以被认为是完全同步的。

新添加的镜像不提供添加镜像之前存在的队列内容的额外形式的冗余或可用性，除非队列已明确同步。由于在发生明确同步时队列变得无响应，因此最好允许正在从中排出消息的活动队列自然同步，并且仅明确同步非活动队列。

启用自动队列镜像时，请考虑所涉及队列的预期磁盘数据集。具有庞大数据集（例如，数十GB或更多）的队列必须将其复制到新添加的镜像中，这会给集群资源（例如网络带宽和磁盘I/O）带来很大的负载。

要查看镜像状态（是否同步）：

手动同步队列：

取消正在进行的同步：

如果你停止一个包含镜像队列leader的RabbitMQ节点，其他节点上的一些镜像将被提升为leader。如果继续停止节点，那么将到达一个镜像队列不再有镜像的点：它仅存在于一个节点上，且该节点上它是leader。如果它的最后一个剩余节点关闭，但是镜像队列被声明为持久的，那么队列中的持久消息将在该节点重新启动后继续存在。

然而，镜像目前无法知道它的队列内容是否已经偏离了它重新加入的leader。因此，当一个镜像重新加入一个镜像队列时，它会丢弃已经拥有的任何持久本地内容并开始为空。

默认情况下，RabbitMQ将拒绝leader节点在受控关闭（即明确停止RabbitMQ服务或关闭操作系统）时提升非同步镜像，以避免消息丢失；相反，整个队列将关闭，就好像未同步的镜像不存在一样。

leader节点不受控制的关闭（即服务器或节点崩溃，或网络中断）仍将触发未同步镜像的提升。

如果您希望在所有情况下都让leader队列移动到未同步的镜像（即，您会选择队列的可用性而不是避免由于未同步的镜像升级而导致的消息丢失），那么将ha-promote-on-shutdown策略键设置为always而不是比它的默认值when-synced。

如果ha-promote-on-failure策略键设置为when-synced，则即使ha-promote-on-shutdown键设置为always，也不会提升未同步的镜像。这意味着如果leader节点发生故障，队列将变得不可用，直到leader恢复。如果leader队列永久丢失，队列将不可用，除非它被删除（这也将删除其所有内容）并重新声明。

当队列的所有镜像都关闭时，可能会丢失队列的leader。在正常操作中，队列关闭的最后一个节点将成为leader，该节点在再次启动时仍然是leader（因为它可能收到了其他镜像没有看到的消息）。

但是，当您调用rabbitmqctlforget_cluster_node时，RabbitMQ将尝试为每个在我们忘记的节点上有其领导者的队列找到当前停止的镜像，并在它再次启动时“提升”该镜像成为新的领导者。如果有多个候选者，将选择最近停止的镜像。

重要的是要理解RabbitMQ只能在forget_cluster_node期间提升停止的镜像，因为任何再次启动的镜像都会清除它们的内容，如上面“停止节点和同步”中所述。因此在停止的集群中移除丢失的leader时，您必须在再次启动镜像之前调用rabbitmqctlforget_cluster_node。

在linux下安装rabbitmq失败怎么解决RabbitMQ是由LShift提供的一个AdvancedMessageQueuingProtocol(AMQP)的开源实现，由以高性能、健壮以及可伸缩性出名的Erlang写成，因此也是继承了这些优点。

AMQP里主要要说两个组件：Exchange和Queue（在AMQP1.0里还会有变动），如下图所示，绿色的X就是Exchange，红色的是Queue，这两者都在Server端，又称作Broker，这部分是RabbitMQ实现的，而蓝色的则是客户端，通常有Producer和Consumer两种类型：

1：mq的安装需要Erlang，所以首先下载Erlang，下载地址：http://www.erlang.org/download.html直接下载源码，编译安装即可。

将下载好的tar包解压编译安装，如下命令：

tar-zxvfotp_src_R16B03-1.tar.gz

cdotp_src_R16B03-1

./configure&&makeinstall

安装过程中可能出现如下错误：

configure:error:

Nocurseslibraryfunctionsfound

configure:error:/bin/sh'/home/niewf/software/erlang_R13B01/erts/configure'

failedforerts

解决方法：

yumlist|grepncurses