rabbitmq集群

①:安装rabbitmq所需要的依赖包 yum install build-essential openssl openssl-devel unixODBC unixODBC-devel make gcc gcc- c++ kernel-devel m4 ncurses-devel tk tc xz ②:下载安装包 wget www.rabbitmq.com/releases/erlang/erlang-18.3-1.el7.centos.x86_64.rpm wget http://repo.iotti.biz/CentOS/7/x86_64/socat-1.7.3.2-5.el7.lux.x86_64.rpm wget www.rabbitmq.com/releases/rabbitmq-server/v3.6.5/rabbitmq-server-3.6.5-1.noarch.rpm ③:安装服务命令 #第一步:安装erlang语言环境 rpm -ivh erlang-18.3-1.el7.centos.x86_64.rpm #第二步:安装socat加解密软件 rpm -ivh socat-1.7.3.2-5.el7.lux.x86_64.rpm #第三步:最后安装rabbitmqrpm -ivh rabbitmq-server-3.6.5-1.noarch.rpm ④

流控机制是用来避免消息发送速率过快而导致服务器难以支撑的情况。内存（memory）和磁盘（Disk space）达到阀值发出的警告相当于全局的流控，一旦触发会阻塞集群或者单机的所有连接（Connection）,这一块我上一篇博文已经讲解过了，而本节的流控是针对单个连接（Connection）的。 单个连接流控（Per-connection flow control）描述的是当发布服务（或发布服务组）向队列发送消息的速度快于队列处理速度时发生的情况，即：queue队列到达了性能瓶颈。 一个连接触发流控时会处于flow的状态，也就意味着这个Connection的状态每秒在blocked和unblocked之间来回切换数次，这样可以将消息发送的速率控制在服务器能够支撑的范围之内。 处于flow状态的Connection和处于running状态的Connection并没有什么不同，这个状态只是告诉系统管理员相应的发送速率受限了；而对于客户端而言，它看到的只是服务器的带宽要比正常情况下小一些。 流控制不只是作用于Connection，同样作用域Channel和queue，从Connection到Channel,再到queue，最后是消息持久化存储形成一个完整的流控链，对于处于流控链中的任意进程，只要该进程阻塞，上游的进程必定全部阻塞。也就是说，如果某个进程达到性能瓶颈

一、前言 Boolean autoAck = false ; channel . basicConsume ( queue_name , autoAck , consumer ) ; 在simple queue 和 work queue(轮询) 处理中，我们设置的消费者的消息监听都采用 channel.basicConsume(queue_name,true, consumer) ，其中参数二 boolean autoAck 为 true ，但在 fair prefetch 公平分发中设置为 false ，这个设置在整个消息队列和消息消费者之间有什么影响呢？ 二、autoAck 参数的讨论 我们都明白一点， autoAck 设置为 true 时，消息队列可以不用在意消息消费者是否处理完消息，一直发送全部消息。但在公平分发中，也就是 autoAck 设置为 false ，在发送一个消息后到没收到消息消费者成功消费消息的信息回执之间，是不会继续给这个消息继续发送消息的。 1、当 autoAck设置为 true 时，也就是自动确认模式，一旦消息队列将消息发送给消息消费者后，就会从内存中将这个消息 删除 。 2、当autoAck设置为 false 时，也就是手动模式，如果此时的有一个消费者宕机，消息队列就会将这条消息继续发送给其他的消费者，这样数据在消息消费者集群的环境下，也就算是不丢失了

一、RabbitMQ集群概念 RabbitMQ 有三种模式：单机模式，普通集群模式，镜像集群模式。单机模式即单独运行一个 rabbitmq 实例，而集群模式需要创建多个 rabbitmq实例。 1、普通集群模式 概念： 默认的集群模式。需要创建多个 RabbitMQ 节点。但对于 Queue 和消息来说，只存在于其中一个节点，其他节点仅同步元数据，即队列的结构信息。 当消息进入Queue后，如果 Consumer 从创建Queue的这个节点消费消息时，可以直接取出来；但如果 consumer 连接的是其他节点，那 rabbitmq 会把 queue 中的消息从创建它的节点中取出并经过连接节点转发后再发送给consumer。 所以 consumer 应尽量连接每一个节点。并针对同一个逻辑队列，要在多个节点建立物理 Queue。否则无论 consumer 连接哪个节点，都会从创建 queue 的节点获取消息，会产生瓶颈。 特点： （1）Exchange 的元数据信息在所有节点上是一致的，而 Queue（存放消息的队列）的完整数据则只会存在于创建它的那个节点上。其他节点只知道这个 queue 的 metadata 信息和一个指向 queue 的 owner node 的指针； （2）RabbitMQ 集群会始终同步四种类型的内部元数据（类似索引）： 　　a.队列元数据：队列名称和它的属性

转自 ： https://my.oschina.net/u/4232045/blog/3117247 在高并发业务场景下，消息队列在流量削峰、解耦上有不可替代的作用。当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。 消息队列这么多，到底该选择哪款消息队列呢？ 选择消息队列的基本标准 虽然这些消息队列在功能和特性方面各有优劣，但我们在选择的时候要有一个基本标准。 首先，必须是开源的产品。开源意味着，如果有一天你使用的消息队列遇到了一个影响你系统业务的 Bug，至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统的问题，而不是等待开发者发布的下一个版本来解决。 其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。流行的好处是，只要使用场景不太冷门，遇到 Bug 的概率会非常低，因为大部分遇到的 Bug，其他人早就遇到并且修复了。在使用过程中遇到的一些问题，也比较容易在网上搜索到类似的问题，然后很快的找到解决方案。还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。 最后，作为一款及格的消息队列，必须具备的几个特性包括： 消息的可靠传递：确保不丢消息； Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息； 性能：具备足够好的性能

RabbitMQ集群搭建 ##CentOS7.2 ##RabbitMQ 3.6.5 ####所有节点运行 下面命令cat >/etc/yum.repos.d/CentOS-OpenStack-liberty.repo <<EOF [centos-openstack-liberty] name=CentOS-7 - OpenStack liberty baseurl=http://vault.centos.org/centos/7.3.1611/cloud/x86_64/openstack-liberty/ gpgcheck=0 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Centos-7 EOF### yum install -y rabbitmq-server systemctl enable rabbitmq-server.service systemctl restart rabbitmq-server.service rabbitmqctl add_user admin admin rabbitmqctl set_user_tags admin administrator rabbitmqctl add_user openstack 123456 rabbitmqctl change_password

什么是队列镜像 默认情况下，RabbitMQ集群中队列的内容位于单个节点（声明该队列的节点）上。 这与交换和绑定相反，交换和绑定始终可以被视为在所有节点上。 可以选择使队列 跨多个节点 进行 镜像 。 每个镜像队列由一个 主服务器 和一个或多个 镜像组成 。 主节点托管在一个通常称为主节点的节点上。 每个队列都有其自己的主节点。 给定队列的所有操作都首先应用于队列的主节点，然后传播到镜像。 这涉及排队发布，向消费者传递消息，跟踪 来自消费者的确认 等。 队列镜像意味着 节点的集群 。 因此，不建议在WAN中使用它（当然，客户端仍然可以根据需要进行远近连接）。 发布到队列的消息将复制到所有镜像。 消费者连接到主服务器，无论他们连接到哪个节点，镜像都会丢弃已在主服务器上确认的消息。 因此，队列镜像可提高可用性，但不会在节点之间分配负载（所有参与节点均完成所有工作）。 如果承载队列主服务器的节点发生故障，则最早的镜像将在同步后提升为新的主服务器。 根据队列镜像参数，也可以升级 不同步的 镜像。 通常有多个术语用于标识分布式系统中的主副本和辅助副本。 本指南通常使用“主”来指代队列的主副本，并使用“镜像”来指代辅助副本。 但是，RabbitMQ CLI工具在历史上一直使用术语“从属”来引用次级。 因此，该术语仍显示在CLI工具的列名中，以实现向后兼容，但最终将被替换。 镜像的配置方式 使用

按照上一篇已经搭好两个rabbitmq单实例，下面把两台单实例组成集群 RabbitMQ集群是一个或几个节点的逻辑分组，每个节点共享用户，虚拟主机，队列，交换，绑定，运行时参数和其他分布式状态 bg： 两台实验机 关闭防火墙和selinux node1 172.16.1.130 mycentos7 node2 172.16.1.79 wikbackup79 节点名称，集群中的唯一标识符，两部分组成，例如rabbit@mycentos7，rabbit默认的，mycentos7主机名，并且要能解析 分别在两台pc编辑hosts CLI工具如何对节点（以及彼此之间的节点）进行身份验证：Erlang Cookie 所以集群要保证/var/lib/rabbitmq/.erlang.cookie（默认）一致，把130的复制到79 开始创建集群 假设两个节点都已经启动 把node1和node2加入集群，在node2上操作 停止node2上的rabbitmq rabbitmqctl stop_app 重置node2rabbitmq rabbitmqctl reset 加入node1 rabbitmqctl join_cluster rabbit@mycentos7 启动node2上的rabbitmq rabbitmqctl start_app 在任意节点查看集群 rabbitmqctl

https://blog.csdn.net/xiangyuan1988/article/details/79383597 一 、RabbitMQ简介 RabbitMQ是基于AMQP实现的一个开源消息组件，主要用于在分布式系统中存储转发消息，由因高性能、高可用以及高扩展而出名的 Erlang 写成。其中，AMQP（Advanced Message Queuing Protocol，即高级消息队列协议），是一个异步消息传递所使用的应用层协议规范，为面向消息的中间件设计。RabbiMQ是EDA事件驱动架构的核心，也是CQRS同步数据的关键。 二、RabbitMQ特点 高可靠：RabbitMQ 提供了多种多样的特性让你在可靠性和性能之间做出权衡，包括持久化、发送应答、发布确认以及高可用性。 高可用队列：支持跨机器集群，支持队列安全镜像备份，消息的生产者与消费者不论哪一方出现问题，均不会影响消息的正常发出与接收。 灵活的路由：所有的消息都会通过路由器转发到各个消息队列中，RabbitMQ内建了几个常用的路由器，并且可以通过路由器的组合以及自定义路由器插件来完成复杂的路由功能。 支持多客户端：对主流开发语言（如：Python、Ruby、.NET、Java、C、PHP、ActionScript等）都有客户端实现。 集群：本地网络内的多个Server可以聚合在一起，共同组成一个逻辑上的broker

一、MQ 全称为 Message Queue, 消息队列（ MQ ） 是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。 消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 二、AMQP 即 Advanced Message Queuing Protocol 高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。 AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布 / 订阅）、可靠性、安全。 三、 Rabbitmq概念： 属于一个流行的开源消息队列系统。属于AMQP( 高级消息队列协议 ) 标准的一个 实现。是应用层协议的一个开放标准，为面向消息的中间件设计。用于在分布式系统中存储转发消息，在 易用性、扩展性、高可用性等方面表现不俗。 消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。 AMQP 的主要特征是面向消息、队列、路由