本篇文章给大家谈谈rabbitmq官方，以及rabbitmq官网对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

本文目录

RabbitMQ分布式部署方案简介RabbitMQ详解1.安装及使用RabbitMQ集群rabbitmq基础配置中文说明文档RabbitMQ分布式部署方案简介当单台RabbitMQ的性能不能满足我们的要求时，我们需要对其进行分布式部署，官方提供了三种方式来实现RabbitMQ的分布式部署，他们之间可以多种组合共同部署，我们分别介绍下

这种方式属于原生的“集群”，该种方式在逻辑上将多台机器联合到一起，对外只相当于一个broker，集群中的所有机器必须运行RabbitMQ和Erlang的相同版本。除了queue以外所有的数据将在集群中复制，queue默认只驻留在一个节点上，但是连接到集群中任何节点的client都可以看到集群中的所有队列，即使它们不在该节点上。要使队列实现高可用，可以使用镜像队列。使用镜像集群的缺点就是节点之间要传输大量的数据。

不像其他软件的集群方案，RabbitMQ集群中节点之间没有主从节点之分。

这种方式利用插件的机制实现集群，它的目标是不通过集群在broker之间传递消息，俩个broker可以有不同的virtualhosts和用户，也可以运行在不同版本的RabbitMQ和Erlang上，broker之间通过AMQP协议进行通讯。Federation使exchange和queue联合起来，Federation exchange和Federation queue可以从其他broker上的exchanges和queues接收消息。Federationexchange可以将消息路由到本地的queue，Federationqueue允许本地消费者从其他broker获取消息。

它也是利用插件的机制实现集群，它将消息可靠的从broker中的queue移动到broker中的exchange，源和目的的broker可以相同或者不同，与Federation类似，使用WAN连接，broker可以运行在不同的Erlang与RabbitMQ版本上，连功能都大致相同，只不过Shovel相比于Federation粒度更细。

由于Federation和Shovel类似，这里把他俩归为一类。

Federation/Shovel：每个broker在逻辑上是独立的；每个节点可以运行在不同的Erlang和RabbitMQ版本；broker之间通过广域网进行连接，消息传递使用AMQP协议；broker之间可以以各种拓扑形式连接，连接可以是双向或者单向；在CAP理论中更侧重于A（可用性）P（分区容错性）；连接到集群中的一个节点只能看见该节点上的queue。

Clustering：逻辑上是相当于一个broker；每个节点Erlang和RabbitMQ版本必须相同；broker之间通过LAN连接，broker之间的消息传递使用Erlang；在CAP理论中侧重于C（一致性）P（分区容错性）；连接到其中一个节点即可看到所有节点上的queue。

最后关于在选择Federation和Shovel之间做出选择，推荐大家看一下stackoverflow上的这篇回答。https://stackoverflow.com/questions/19357272/when-to-use-rabbitmq-shovels-and-when-federation-plugin

RabbitMQ详解1.安装及使用brewinstallrabbitmq

Homebrew是Mac的软件包管理器，如果电脑上没有Homebrew可以通过下面的指令安装，官网地址Homebrew。

/usr/bin/ruby-e"$(curl-fsSLhttps://raw.githubusercontent.com/Homebrew/install/master/install)"

/usr/local/etc/rabbitmq

前台启动：rabbitmq-server

后台启动：rabbitmq-server-detached

rabbitmqctlstatus

前台关闭：controlc

后台关闭：rabbitmqctlstop

可以通过rabbitmqctl命令来进行创建、删除、查看用户、分配用户权限等操作，更详细的操作列表可以查阅官方文档rabbitmqctl官方文档，或通过rabbitmqctl--help来查看。

RabbitMQ为了控制用户的权限，一共为用户分配了五种角色，如下所示

RabbitMQ的权限控制是以vhost为单元的，可以把vhost暂时理解为一个权限控制组，后面会进行详细解释，详细的权限管理可以查阅官方文档AccessControlinRabbitMQ。

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。

rabbitmq基础配置中文说明文档本文为官方文档翻译版本rabbitmq3.7.5版本，原地址：https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq.conf.example。以#开头的行为配置，key和等号以及value之间尽量保持有一个空格。以下的"默认"指的为在没有添加配置文件或者该key没有配置。

rabbitmq是使用基于tcp的amqp协议通信(如果需要ssl，可参考这里)，所以这里都是监听的tcp的端口。rabbitmq支持监听多端口，并支持指定网卡的ipv4和ipv6。格式为listeners.tcp.${name}=${value}，name可以是任意不重复的值，如：defaul、local、local_v6等。value的格式有：

(1)包括了(2)和(3)，(2)包括了(4)和(6)，(3)包括了(5)和(7)。下面对应的为其中情况的配置，按需求进行配置，不需要都配，大部分情况只配置(1)。默认的配置为listeners.tcp.default=5672

例:

接受TCP侦听器连接的Erlang进程数。一旦打开了一个使用tcp连接的套接字，它就始终保持打开状态，直至任何一方关闭它或因为一个错误而终止。在建立一个连接时，一般为每一次请求产生一个新进程，num_acceptors就是控制产生新进程的个数。假设有一个监听进程，其任务是等待传入的tcp请求。只要一个请求到达，响应该连接请求的进程就变成了接收进程。默认的配置为num_acceptors.tcp=10。

例:

AMQP0-9-1握手（socket连接和TLS握手之后）的最大时间，以毫秒为单位。

默认的配置为handshake_timeout=10000。

例:

设置为'true'以在接受一个连接时执行反DNS反查询。在rabbitmqctl中和web管理中将显示主机名称而不是IP地址。默认的配置为reverse_dns_lookups=true。

例:

开启后的效果

仅允许通过本地（即localhost）连接到代理的用户列表。如果您希望允许guest用户远程连接，则需要将其更改为loopback_users=none。

要将其他用户限制为仅限localhost的连接，请像这样执行（monitoring是用户的名称）：loopback_users.monitoring=true。默认的配置为loopback_users.guest=true。推荐设置loopback_users.guest=false。

例:

关于ssl的配置，内容比较多，参考官网。默认不配置。

选择要使用的认证/授权后端。可以配置ldap相关的设置。具体可以参考access-control。internal为由rabbitmq内部处理，默认的配置为auth_backends.1=internal。

例:

RabbitMQ具有对各种SASL认证机制的可插拔支持。服务器内置了三种这样的机制：PLAIN，AMQPLAIN和RABBIT-CR-DEMO，以及EXTERNAL可作为插件使用。您还可以通过在插件中实现rabbit_auth_mechanism行为来实现自己的身份验证机制。有关常规插件开发的更多信息，请参阅插件开发指南。默认的配置为PLAIN和AMQPLAIN。

内置的机制：

例:

有关rabbitmq-auth-mechanism-ssl插件的配置，查看:https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl

SSLhandshake超时时间,毫秒为单位。默认的配置为ssl_handshake_timeout=5000

。

例:

rabbitmq的用户的密码加密算法。修改该值只会影响新创建的用户，对应老用户需要重置密码进行更新。一般情况下不更改。默认的配置为password_hashing_module=rabbit_password_hashing_sha256。要使用SHA-512，请设置为rabbit_password_hashing_sha512。

例:

和web端的Importdefinitions、Exportdefinitions有关。好像没啥用==。

默认的用户及其权限和vhost。如果一个connect没有配置以下的配置，则使用默认值进行连接。

默认用户的tag。默认的配置default_user_tags.administrator=true。一般不需要改。

例:

heartbeat通常用来检测通信的对端是否存活（未正常关闭socket连接而异常crash）。其基本原理是检测对应的socket连接上数据的收发是否正常，如果一段时间内没有收发数据，则向对端发送一个心跳检测包，如果一段时间内没有回应则认为心跳超时，即认为对端可能异常crash了。

rabbitmq也不例外，heatbeat在客户端和服务端之间用于检测对端是否正常，即客户端与服务端之间的tcp链接是否正常。

heartbeat检测时间间隔的设置：

这里要注意的是：如果时间间隔配置为0，则表示不启用heartbeat检测。

例:

设置amqp协议最大允许的字节数。默认的配置为frame_max=131072(单位为字节，也就是128k)，注意该值不要设置过大，如果一条消息比较大(如传输文件)，可以通过PublishConfirm和ConsumerAcknowledgement机制，如设置过大，那么broker内存会容易被占完。也不要设置过小，保持在128k-1m之间。引用:使用RabbitMQ传输大文件，保证其完整性

例:

初始化时的最大字节，不知道哪里使用的。原文：Setthemaxframesizetheserverwillacceptbeforeconnectiontuningoccurs。

例:

设置每个连接的最大允许通道数量。0表示“没有限制”。默认的配置为channel_max=128。

例:

tcp连接相关的配置。尽量不要改。以下为默认的配置

例:

设置rabbitmq使用内存的阈值。有相对和绝对两种阈值。默认为vm_memory_high_watermark.relative=0.4。

队列开始将消息导出到光盘来释放内存的高水位限制的值。

例如，当vm_memory_high_watermark被设置为0.4并且该值被设置为0.5时，

可以在节点使用总可用RAM的20％时开始分页。大于1.0的值可能很危险，应谨慎使用。

一种替代方法是使用持久队列并发布消息，作为持久性。有了这个组合队列将消息更快地移动到磁盘。

另一种方法是配置队列来分页所有消息（都是持久和瞬态）到磁盘。

尽可能参阅http://rabbitmq.com/lazy-queues.html。

例:

内存使用情况报告策略。可以是以下之一，默认的配置为rss：

allocated：使用Erlang内存分配器统计信息

rss：使用操作系统RSS内存报告。这使用特定于操作系统的手段，并可能启动短暂的子进程。

legacy：使用legacy内存报告（运行时考虑使用多少内存）。这个策略相当不准确。

erlang：与legacy相同，为了向后兼容而保留

例:

根据watermarks检查内存级别。没发现具体作用。

例:

可用内存总量，不使用特定于操作系统的方式从环境中推断内存。只有当节点可用的实际最大RAM数量与节点将要推断的值不匹配时，才应使用这种方法。该值可以设置为整数个字节，或者可以以信息单位（例如“8GB”）设置。例如，当该值设置为4GB时，该节点会认为它在具有4GBRAM的计算机上运行。默认不设置该值。

例:

和vm_memory_high_watermark类似，disk_free_limit是控制硬盘的使用阈值。RabbitMQ正在存储数据的分区的磁盘可用空间限制。当可用磁盘空间低于此限制时，将触发流量控制。该值可以相对于RAM的总量或以字节或以信息单位表示的绝对值（例如"50MB"或"5GB"或"5KB"）来设置，或者，我们可以设置相对于可用RAM总量的限制。低于1.0的值可能很危险，应谨慎使用。默认为disk_free_limit.absolute=50MB。

例:

网络分裂。一种在系统的任何两个组之间的所有网络连接同时发生故障后所出现的情况。发生这种情况时，分裂的系统双方都会从对方一侧重新启动应用程序，进而导致重复服务或裂脑。由网络分裂造成的最为严重的问题是它会影响共享磁盘上的数据。默认为ignore模式。如何处理网络分裂？详细的文档可以参考官网文档

可用的模式是：

在消息中镜像同步批量大小。增加这将加快同步，但批量总大小（以字节为单位）不得超过2GiB。该设置可用于RabbitMQ3.6.0或更高版本。默认的配置为mirroring_sync_batch_size=4096(4k)。

例:

集群相关的配置，为了形成一个集群，新的（“空白”）节点需要能够发现他们的同伴。这可以使用各种机制（后端）来完成。有些机制假定所有集群成员都提前知道（例如，在配置文件中列出），其他机制是动态的（节点可以动态增删）。

内置的发现机制如下:

cluster_formation.node_type：节点类型。默认为disc。

cluster_keepalive_interval：像集群里的其他子节点发送存活消息的间隔(毫秒)。默认为cluster_keepalive_interval=10000

统计相关，与web管理插件显示有关。可配置的值如下：

例:

设置为true，以便使用HiPE预编译RabbitMQ的部分，这是Erlang的即时编译器。这会以增加启动时间为代价来提高服务器吞吐量。

您可能会看到启动时延迟几分钟的成本提高20-50％。这些数据非常依赖于工作负载和硬件。

HiPE支持可能不会编译到您的Erlang安装中。如果不是，启用此选项只会导致显示一条警告消息，启动将按正常进行。例如，Debian/Ubuntu用户需要安装erlang-base-hipe软件包。

HiPE在某些平台上完全不可用，特别包括Windows。

HiPE在17.5之前的Erlang/OTP版本中存在已知问题。HiPE强烈建议使用最新的Erlang/OTP版本。默认的配置为hipe_compile=false。

等待集群中的Mnesiatables变得可用时使用的超时。默认的配置mnesia_table_loading_retry_timeout=30000。

在等待集群中的Mnesiatables可用时，需要重试的次数。默认的配置mnesia_table_loading_retry_limit=10。

在消息的字节数中，消息将被直接嵌入到队列索引中。详情请看persistertuning。默认的配置queue_index_embed_msgs_below=4096。

是否启用后台定期强制GC为“等待”状态运行节点上的所有Erlang进程。

禁用后台GC可以减少客户端操作的延迟，保持启用状态可以减少二进制堆的RAM使用量（请参阅https://www.erlang-solutions.com/blog/erlang-garbage-collector.html）。

在尝试此选项之前，请查看内存（http://www.rabbitmq.com/memory-use.html）。

默认的配置background_gc_enabled=false，当配置为true时，可以设置gc的间隔，默认的配置为background_gc_target_interval=60000(毫秒)。

设置是否启用代理，启用后不能直连到broker。默认的配置proxy_protocol=false。

未知

有关web管理后台的配置。

查看http://www.rabbitmq.com/stomp.html。

http://www.rabbitmq.com/mqtt.html

查看https://github.com/rabbitmq/rabbitmq-amqp1.0

查看http://rabbitmq.com/ldap.html。

文章分享结束，rabbitmq官方和rabbitmq官网的答案你都知道了吗？欢迎再次光临本站哦！

股市行情

好客百科

Bitget下载