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

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

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

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

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

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

默认配置文件/usr/lib/rabbitmq/lib/rabbitmq_server-3717/ebin/rabbitapp

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

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

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

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

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

文件路径/var/lib/rabbitmq/erlangcookie

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

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

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

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

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

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

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

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

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

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

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

管理端界面：

命令行：

为避免集群中的某个节点托管大多数leader队列，因此导致高负载，leader队列应合理均匀的分布在集群节点上。控制leader队列分布节点策略有三种，可以在rabbitmqconf文件中定义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（因为它可能收到了其他镜像没有看到的消息）。

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

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

按照JMS规范，为了保证可靠性，所有的消息都应该是发送到broker，然后交由broker来投递的。也即是说其实JMS是不建议或不支持传输文件的。

对于比较小的文件，简单的处理方式是先读取所有的文件成byte[]，然后使用ByteMessage，把文件数据发送到broker，像正常的message一样处理。对于大文件，例如1GB以上的文件，这么搞直接把client或是broker给oom掉了。

这种方式仅仅适用于小文件的传输。特别是如果broker端使用数据库作为存储，message序列化以后存放于blob字段，文件传输频繁或是稍微有点大，写入效率极低。

直接传输文件

为了解决传输大文件的问题，ActiveMQ在jms规范之外引入了jms streams的概念。PTP模式下，连到同一个destination的两端，可以通过broker中转来传输大文件。

发送端使用connectioncreateOutputStream打开一个输出流，往流里写文件。

OutputStream out =connectioncreateOutputStream(destination);

接收端则简单的使用connectioncreateInputStream拿到一个输入流，从中读取文件数据即可。

InputStream in = connectioncreateInputStream(destination)

这个问题有点搞笑！！！

用户多，不代表你服务器访问量大，访问量大不一定你服务器压力大！我们换成专业点的问题，高并发下怎么优化能避免服务器压力过大？

1，整个架构:可采用分布式架构，利用微服务架构拆分服务部署在不同的服务节点，避免单节点宕机引起的服务不可用！

2，数据库:采用主从复制，读写分离，甚至是分库分表，表数据根据查询方式的不同采用不同的索引比如btree，hash，关键字段加索引，sql避免复合函数，避免组合排序等，避免使用非索引字段作为条件分组，排序等！减少交互次数，一定不要用select！

3，加缓存:使用诸如memcache，redis，ehcache等缓存数据库定义表，结果表等等，数据库的中间数据放缓存，避免多次访问修改表数据！登录信息session等放缓存实现共享！诸如商品分类，省市区，年龄分类等不常改变的数据，放缓存，不要放数据库！

同时要避免缓存雪崩和穿透等问题的出现导致缓存崩溃！

4，增量统计:不要实时统计大量的数据，应该采用晚间定时任务统计，增量统计等方式提前进行统计，避免实时统计的内存，CPU压力！

5，加服务器:等大文件，一定要单独经过文件服务器，避免IO速度对动态数据的影响！保证系统不会因为文件而崩溃！

6，HTML文件，枚举，静态的方法返回值等静态化处理，放入缓存！

7，负载均衡:使用nginx等对访问量过大的服务采用负载均衡，实现服务集群，提高服务的最大并发数，防止压力过大导致单个服务的崩溃！

8，加入搜索引擎:对于sql中常出现的like，in等语句，使用lucence或者solr中间件，将必要的，依赖模糊搜索的字段和数据使用搜索引擎进行存储，提升搜索速度！#注意:全量数据和增量数据进行定时任务更新！

9，使用消息中间件:对服务之间的数据传输，使用诸如rabbitmq，kafka等等分布式消息队列异步传输，防止同步传输数据的阻塞和数据丢失！

10，抛弃tomcat:做web开发，接触最早的应用服务器就是tomcat了，但是tomcat的单个最大并发量只能不到1w！采取netty等actor模型的高性能应用服务器！

11，多线程:现在的服务器都是多核心处理模式，如果代码采用单线程，同步方式处理，极大的浪费了CPU使用效率和执行时间！

12，避免阻塞:避免bio，blockingqueue等常常引起长久阻塞的技术，而改为nio等异步处理机制！

13，CDN加速:如果访问量实在过大，可根据请求来源采用CDN分流技术，避免大流量完成系统崩溃！

14，避免低效代码:不要频繁创建对象，引用，少用同步锁，不要创建大量线程，不要多层for循环！

还有更多的细节优化技术，暂时想不起来了！

解决方案有有很多种,因为错误的原因是不通的,如果出现拒绝连接的错误,在下提供几个个决绝方案

这个需要你重新打jar包,因为这把大部分都是配置文件的错误,

去本地的idea中看applicationyml配置文件查看数据连接的方式是否出错,

比如数据库地址,本地的一般都是localhost或127001,

如果需要远程连接数据库,这时你就需要更改数据库的连接地址

还有就是数据库的用户密码是否正确,连接的数据库名称是否正确

如果你的数据库的版本较高的话要使用cj连接

driver-class-name: commysqlcjjdbcDriver

登录后复制

java

数据库

linux

镇江市民请关注领取补贴！

巨摩互动

广告



javanetConnectException: Connection refused问题解决办法

66下载·0评论

2020年9月1日

出现 javanetConnectException: Connection refused 异常的原因及解决方法

52W阅读·0评论·3点赞

2018年11月23日

linux用java -jar启动jar包缓慢问题

502阅读·1评论·1点赞

2022年10月21日

解决： javanetConnectException: Connection refused: connect

437W阅读·19评论·53点赞

2018年7月5日

全网最全Linux 运行jar包的几种方式

33W阅读·2评论·24点赞

2022年1月25日

SpringBoot集成rabbitmq错误:orgspringframeworkamqpAmqpConnectException: javanetConnectException的解决办法

120W阅读·20评论·14点赞

2018年9月10日

高清播放机，大全，详情！



精选推荐

广告

Caused by: javanetConnectException: 拒绝连接

18W阅读·0评论·9点赞

2020年2月11日

报错：Caused by: javanetConnectException: Connection refused: connect

8983阅读·0评论·0点赞

2022年1月10日

h

前言

开源社区有好多优秀的队列中间件，比如RabbitMQ和Kafka，每个队列都貌似有其特性，在进行工程选择时，往往眼花缭乱，不知所措。对于RabbitMQ和Kafka，到底应该选哪个？

RabbitMQ架构

概念

RabbitMQ是一个分布式系统

broker：每个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列 *** 作请求。

master queue：每个队列都分为一个主队列和若干个镜像队列。

mirror queue：镜像队列，作为master queue的备份。在master queue所在节点挂掉之后，系统把mirror queue提升为master queue，负责处理客户端队列 *** 作请求。注意，mirror queue只做镜像，设计目的不是为了承担客户端读写压力。

如上图所示，集群中有两个节点，每个节点上有一个broker，每个broker负责本机上队列的维护，并且borker之间可以互相通信。集群中有两个队列A和B，每个队列都分为master queue和mirror queue（备份）。那么队列上的生产消费怎么实现的呢？

队列消费

如上图有两个consumer消费队列A，这两个consumer连在了集群的不同机器上。RabbitMQ集群中的任何一个节点都拥有集群上所有队列的元信息，所以连接到集群中的任何一个节点都可以，主要区别在于有的consumer连在master queue所在节点，有的连在非master queue节点上。

因为mirror queue要和master queue保持一致，故需要同步机制，正因为一致性的限制，导致所有的读写 *** 作都必须都 *** 作在master queue上（想想，为啥读也要从master queue中读？和数据库读写分离是不一样的。），然后由master节点同步 *** 作到mirror queue所在的节点。即使consumer连接到了非master queue节点，该consumer的 *** 作也会被路由到master queue所在的节点上，这样才能进行消费。

队列生产

原理和消费一样，如果连接到非 master queue 节点，则路由过去。

不足

由于master queue单节点，导致性能瓶颈，吞吐量受限。虽然为了提高性能，内部使用了Erlang这个语言实现，但是终究摆脱不了架构设计上的致命缺陷。

Kafka

说实话，Kafka我觉得就是看到了RabbitMQ这个缺陷才设计出的一个改进版，改进的点就是：把一个队列的单一master变成多个master，即一台机器扛不住qps，那么我就用多台机器扛qps，把一个队列的流量均匀分散在多台机器上不就可以了么？注意，多个master之间的数据没有交集，即一条消息要么发送到这个master queue，要么发送到另外一个master queue。

这里面的每个master queue 在Kafka中叫做Partition，即一个分片。一个队列有多个主分片，每个主分片又有若干副分片做备份，同步机制类似于RabbitMQ。

如上图，我们省略了不同的queue，假设集群上只有一个queue（Kafka中叫Topic）。每个生产者随机把消息发送到主分片上，之后主分片再同步给副分片。

队列读取的时候虚拟出一个Group的概念，一个Topic内部的消息，只会路由到同Group内的一个consumer上，同一个Group中的consumer消费的消息是不一样的；Group之间共享一个Topic，看起来就是一个队列的多个拷贝。所以，为了达到多个Group共享一个Topic数据，Kafka并不会像RabbitMQ那样消息消费完毕立马删除，而是必须在后台配置保存日期，即只保存最近一段时间的消息，超过这个时间的消息就会从磁盘删除，这样就保证了在一个时间段内，Topic数据对所有Group可见（这个特性使得Kafka非常适合做一个公司的数据总线）。队列读同样是读主分片，并且为了优化性能，消费者与主分片有一一的对应关系，如果消费者数目大于分片数，则存在某些消费者得不到消息。

由此可见，Kafka绝对是为了高吞吐量设计的，比如设置分片数为100，那么就有100台机器去扛一个Topic的流量，当然比RabbitMQ的单机性能好。

总结

本文只做了Kafka和RabbitMQ的对比，但是开源队列岂止这两个，ZeroMQ，RocketMQ，JMQ等等，时间有限也就没有细看，故不在本文比较范围之内。

所以，别再被这些五花八门的队列迷惑了，从架构上找出关键差别，并结合自己的实际需求（比如本文就只单单从吞吐量一个需求来考察）轻轻松松搞定选型。最后总结如下：

吞吐量较低：Kafka和RabbitMQ都可以。

吞吐量高：Kafka。

以上就是关于RabbitMQ集群全部的内容，包括:RabbitMQ集群、rabbitmq消息阻塞如何解决、当用户过多时，如何对服务器进行优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！