rabbitmq集群

转自： https://www.cnblogs.com/rjzheng/p/8994962.html 引言 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。 小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。 庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点 复习要点 本文大概围绕如下几点进行阐述: 为什么使用消息队列？ 使用消息队列有什么缺点? 消息队列如何选型? 如何保证消息队列是高可用的？ 如何保证消息不被重复消费? 如何保证消费的可靠性传输? 如何保证消息的顺序性？ 我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大 正文 1、为什么要使用消息队列? 分析 :一个用消息队列的人，不知道为啥用，这就有点尴尬

首先，rabbitMQ是一款开源，ERlang编写的，基于AMQP协议的，消息中间件； 它可以做到：解耦、异步、削疯限流； 挂机可能造成稳定性问题；加入系统的复杂性； 如何保证rabbitMQ的高可用，搭建集群； 如何做到重复消费：确保消息唯一性，做唯一标识； 然后，kafka是apache一款分布式发布订阅消息系统。 它能做到缓冲和削峰、解耦、冗余。 区别： 从消息确认来说 rabbitMQ以brocker代理为中心，有消息确认机制； kfka：以consumer为中心，没有消息确认机制。 从批量处理来说 rabbitMQ支持事务，不支持批量操作，吞吐量小 Kafka：内部消息是可以做批量处理，消息处理效率高，吞吐量高 从负载均衡来说 rabbitMQ不支持负载均衡，需要loadbalance支持 kafka的采用zK来协调负载均衡问题，zk通过轮询的方式发送消息到brocker上； 来源： https://www.cnblogs.com/zym627270054/p/11783648.html

原文链接： https://blog.csdn.net/qq_42629110/article/details/84965084 1.什么是rabbitmq 采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦 2.为什么要使用rabbitmq 1.在分布式系统下具备异步,削峰,负载均衡等一系列高级功能; 2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。 3.实现消费者和生产者之间的解耦。 4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。 5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。 3.使用rabbitmq的场景 1.服务间异步通信 2.顺序消费 3.定时任务 4.请求削峰 4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？ 发送方确认模式： 将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。 一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。 如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。 发送方确认模式是异步的

使用场景 在我们秒杀抢购商品的时候，系统会提醒我们稍等排队中，而不是像几年前一样页面卡死或报错给用户。 像这种排队结算就用到了消息队列机制，放入通道里面一个一个结算处理，而不是某个时间断突然涌入大批量的查询新增把数据库给搞宕机，所以RabbitMQ本质上起到的作用就是削峰填谷，为业务保驾护航。 为什么选择RabbitMQ 现在的市面上有很多MQ可以选择，比如ActiveMQ、ZeroMQ、Appche Qpid，那问题来了为什么要选择RabbitMQ？ 除了Qpid，RabbitMQ是唯一一个实现了AMQP标准的消息服务器； 可靠性，RabbitMQ的持久化支持，保证了消息的稳定性； 高并发，RabbitMQ使用了Erlang开发语言，Erlang是为电话交换机开发的语言，天生自带高并发光环，和高可用特性； 集群部署简单，正是应为Erlang使得RabbitMQ集群部署变的超级简单； 社区活跃度高，根据网上资料来看，RabbitMQ也是首选； 工作机制 生产者、消费者和代理 在了解消息通讯之前首先要了解3个概念：生产者、消费者和代理。 生产者：消息的创建者，负责创建和推送数据到消息服务器； 消费者：消息的接收方，用于处理数据和确认消息； 代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。 消息发送原理

采用两台centos7机器搭建普通模式的 RabbitMQ 机器 mq01 (主机名) 192.168.100.177 mq02 (主机名) 192.168.100.200 centos6 查看当前的hostname 编辑network文件修改hostname行（重启生效） centos7 centos7新增hostnamectl工具，修改后即可并永久生效 hostnamectl set-hostname mq01 关于hosts文件的说明 RabbitMQ 机器内部通讯的端口是 4369 和 25672 ，如果防火墙上没有放开这两个端口，后续的 join_cluster 操作会失败。使用 firewall-cmd 工具分别在两台机上都打开端口。 1、集群配置 如果RabbitMQ还没有启动，那么采用后台服务的模式启动。 rabbitmq-server -detached 在上述的两台机器上安装 RabbitMQ 完成之后，在/var/lib/rabbitmq下有个隐藏文件.erlang.cookie，这文件存储的内容是cookie值。 RabbitMQ 的集群依赖 erlang 集群，而 erlang 集群是通过这个cookie进行通信认证的，因此我们做集群的第一步就是统一cookie值。 通过 scp 命令把其中一台机器上的cookie文件拷贝覆盖另一台机器上的cookie文件

原文地址 消息的可靠性是RabbitMQ的一大特色，那么RabbitMQ是如何保证消息可靠性的呢――消息持久化。 为了保证RabbitMQ在退出或者crash等异常情况下数据没有丢失，需要将queue，exchange和Message都持久化。 queue的持久化 queue的持久化是通过durable=true来实现的。 一般程序中这么使用： Connection connection = connectionFactory . newConnection (); Channel channel = connection . createChannel (); channel . queueDeclare ( "queue.persistent.name" , true , false , false , null ); 关键的是第二个参数设置为true,即durable=true. Channel类中queueDeclare的完整定义如下： /** * Declare a queue * @see com.rabbitmq.client.AMQP.Queue.Declare * @see com.rabbitmq.client.AMQP.Queue.DeclareOk * @param queue the name of the queue * @param durable

搭建 RabbitMQ Server 高可用集群 阅读目录： 准备工作 搭建 RabbitMQ Server 单机版 RabbitMQ Server 高可用集群相关概念 搭建 RabbitMQ Server 高可用集群 搭建 HAProxy 负载均衡 因为公司测试服务器暂不能用，只能在自己电脑上重新搭建一下 RabbitMQ Server 高可用集群，正好把这个过程记录下来，以便日后查看。 公司测试服务器上的 RabbitMQ 集群，我搭建的是三台服务器，因为自己电脑空间有限，这边只能搭建两台服务器用作高可用集群，用的是 Vagrant 虚拟机管理工具。 环境介绍： RabbitMQ 节点 IP 地址 工作模式 node1 192.168.1.50 DISK CentOS 7.0 - 64λ node2 192.168.1.51 DISK CentOS 7.0 - 64λ 整体架构： 1. 准备工作 首先，在 node1 服务器上，修改 vi /etc/hostname ： node1 在 node2 服务器上，修改 vi /etc/hostname ： node2 然后在 node1 服务器上，修改 vi /etc/hosts ： node1 192 .168 .1 .50 node2 192 .168 .1 .51 127 .0 .0 .1 node1 ::1 node1 在

一、前言 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 时，也就是手动模式，如果此时的有一个消费者宕机，消息队列就会将这条消息继续发送给其他的消费者，这样数据在消息消费者集群的环境下，也就算是不丢失了

一、协议 AMQP协议分层类似于OSI或TCP/IP协议分层。从图中可以看出分三层： 图1 AMQP协议分层图 1、Model Layer 规范服务器端Broker的行为。 2、Session Layer 定义客户端与服务器端Broker的Context。 3、Transport Layer 传输二进制数据流。 二、模型 AMQP服务器Broker主要由Exchange和Message Queue组成，主要功能是Message的路由Routing和缓存Buffering。 图2 AMPQ服务器模型图 Exchange接受Producer发送的Message并根据不同路由算法将Message发送到Message Queue。 Message Queue会在Message不能被正常消费时将其缓存起来，但是当Consumer与Message Queue之间的连接通畅时，Message Queue将Message转发给Consumer。 Message由Header和Body组成，Header是由Producer添加的各种属性的集合，包括Message是否客被缓存、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。 Exchange与Message Queue之间的关联通过Binding来实现。Exchange在与多个Message

原文： https://blog.csdn.net/Tech_Salon/article/details/82890431 使用 Pika 连接 rabbitmq 集群 使用 python 编程经常会用到 pika 来向 rabbitmq 发送消息，单个 rabbitmq 节点连接比较简单，本文介绍使用 rabbitmq 集群情况下的连接方式。 vip 连接方式 在 client 与 rabbitmq server 之间通过 haproxy 等负载均衡来提供 vip，我使用的环境就是采用这种方式，但是遇到某一节点挂掉时再访问 vip 连接 rabbitmq 集群会连接失败，常见 log 如下： <URLParameters host=10.10.11.1 port=5672 virtual_host=/ ssl=False> DEBUG:pika.adapters.select_connection:Using EPollPoller DEBUG:pika.callback:Added: {'callback': <bound method SelectConnection._on_connection_start of <SelectConnection CLOSED socket=None params=<URLParameters host=10.10.11.1 port