rabbitmq集群

作者 微信:tangy8080 电子邮箱:914661180@qq.com 更新时间：2019-08-12 20:42:25 星期一 欢迎您订阅和分享我的订阅号,订阅号内会不定期分享一些我自己学习过程中的编写的文章 如您在阅读过程中发现文章错误,可添加我的微信 tangy8080 进行反馈.感谢您的支持。 文章主题 介绍在rabbit的使用过程中经常用的一些参数 前置条件 有一些rabbit的使用经验 QueueDeclare中的参数详细说明 queue 队列的名称 durable 是否是持久化的,队列的声明默认是存放到内存中的，如果rabbitmq重启会丢失，如果想重启之后还存在就要使队列持久化，保存到Erlang自带的Mnesia数据库中，当rabbitmq重启之后会读取该数据库 exclusive 是否排外.排外有以下两个特性 A.当连接关闭时connection.close()该队列是否会自动删除 B.该队列是否是私有的private,其他通道channel是不能访问的，如果强制访问会报异常：com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=405, reply-text=RESOURCE_LOCKED

作者 微信:tangy8080 电子邮箱:914661180@qq.com 更新时间：2019-07-05 17:11:53 星期五 欢迎您订阅和分享我的订阅号,订阅号内会不定期分享一些我自己学习过程中的编写的文章 如您在阅读过程中发现文章错误,可添加我的微信 tangy8080 进行反馈.感谢您的支持。 索引 nginx 1.nginx安装和基本配置 2.了解nginx常用的配置 3.keepalived+脚本实现nginx高可用 消息中间件rabbitmq 1.rabbitmq 集群安装及负载均衡设置 2.hello rabbitmq 3.Work Queues 4.Direct交换机之使用指定routingkey完成日志记录场景 5.Fanout交换机之新订单通知商户场景 6.Header交换机之模拟验证用户身份 7.Topic交换机之模拟文件分类 8.rabbitmq RPC模拟微服务架构中的服务调用 9.[完]其他常用的rabbitmq的参数和设置 Redis 1.初识Redis 2.API的理解和使用 3.小功能大用处 4.Redis客户端的使用 来源： https://www.cnblogs.com/gytangyao/p/11406079.html

作者 微信:tangy8080 电子邮箱:914661180@qq.com 更新时间：2019-07-22 22:49:50 星期一 欢迎您订阅和分享我的订阅号,订阅号内会不定期分享一些我自己学习过程中的编写的文章 如您在阅读过程中发现文章错误,可添加我的微信 tangy8080 进行反馈.感谢您的支持。 文章主题 从一个最简单的hello rabbitmq开始,逐步了解rabbitmq 本文源码： http://admin@gitblit.honeysuckle.site/r/public/rabbitmq/Solution2.git 前置条件 已经构建好了一个rabbitmq集群 正文 认识rabbitmq 首先,rabbitmq是一个消息中间件.它主要解决了应用耦合、异步处理、流量削锋等问题。 它具有以下特点： 解耦 假如现在您需要做一个通知中心,您需要将您的消息通知到 A,B，C. 经验稍差的同学可能会直接代码引用,通知中心直接引用A,B,C的代码.一旦有新的消息,直接调用A B C的逻辑处理.但是这样带来一个问题,现在如果D也需要收到消息.难道通知中心再引用一次D吗? 这显然是一种糟糕的设计. 一种比较优雅的实现就是观察者模式.A,B,C观察通知中心的消息.如果有新的消息.则做出相应的逻辑. 如果D现在需要知道通知中心的消息,那么它只需要订阅通知中心的消息就可以了

前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子，那么选择一款合适自己的消息中间件显得尤为重要。就算是前者，那么在自研出稳定且可靠的相关产品之前还是会经历这样一个选型过程。 在整体架构中引入消息中间件，势必要考虑很多因素，比如成本及收益问题，怎么样才能达到最优的性价比？虽然消息中间件种类繁多，但是各自都有各自的侧重点，选择合适自己、扬长避短无疑是最好的方式。如果你对此感到无所适从，本文或许可以参考一二。 各类消息队列简述 ActiveMQ是Apache出品的

原 消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局https://blog.csdn.net/u013256816/article/details/79838428版权声明：本文为博主原创文章，未经博主朱小厮允许不得转载。 https://blog.csdn.net/u013256816/article/details/79838428 本文收录于InfoQ，未经允许不得转载。 一、前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。 目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子

Infi-chu: http://www.cnblogs.com/Infi-chu/ Kafka是LinkedIn在2012年发布的开源的消息发布订阅系统，他主要用于处理活跃的流式数据、大数据量的数据处理上 RabbitMQ由Erlang语言开发，主要用在实时的对可靠性要求较高的消息传递上 1.架构模型 RabbitMQ遵循AMQP协议，RabbitMQ的borker由Exchange、Binding和Queue组成，其中Exchange和Binding组成了消息的路由键，客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费，有消息确认机制 Kafka遵循从一般的MQ结构，producer、broker、consumer为中心，消息的消费信息保存在客户端consumer上，consumer根据消费的点，从broker上批量pull数据，无消息确认机制 2.吞吐量 RabbitMQ吞吐量较低，RabbitMQ支持对消息的可靠传递，支持事物，不支持批量的操作，基于存储的可靠性要求存储可以采用内存或硬盘 Kafka吞吐量较高，内部采用消息的批量处理，zero-copy机制，数据的存储和获取时候本地磁盘顺序批量操作，复杂度为o(1)，消息处理效率较高 3.可用性 RabbitMQ支持miror和queue，当主queue失效时

1、为什么要使用消息队列? 分析:一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。 回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。 我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住

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

大家平时也有用到一些消息中间件(MQ)，但是对其理解可能仅停留在会使用API能实现生产消息、消费消息就完事了。 对MQ更加深入的问题，可能很多人没怎么思考过。 比如，你跳槽面试时，如果面试官看到你简历上写了，熟练掌握消息中间件，那么很可能给你发起如下 4 个面试连环炮! 为什么要使用MQ? 使用了MQ之后有什么优缺点? 怎么保证MQ消息不丢失? 怎么保证MQ的高可用性? 本文将通过一些场景，配合着通俗易懂的语言和多张手绘彩图，讨论一下这些问题。 为什么要使用MQ? 相信大家也听过这样的一句话：好的架构不是设计出来的，是演进出来的。 这句话在引入MQ的场景同样适用，使用MQ必定有其道理，是用来解决实际问题的。而不是看见别人用了，我也用着玩儿一下。 其实使用MQ的场景有挺多的，但是比较核心的有3个： 异步、解耦、削峰填谷 异步 我们通过实际案例说明：假设A系统接收一个请求，需要在自己本地写库执行SQL，然后需要调用BCD三个系统的接口。 假设自己本地写库要3ms，调用BCD三个系统分别要300ms、450ms、200ms。 那么最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，可能用户会感觉太慢了。 此时整个系统大概是这样的： 但是一旦使用了MQ之后，系统A只需要发送3条消息到MQ中的3个消息队列，然后就返回给用户了。 假设发送消息到MQ中耗时20ms

一、什么是RabbitMQ RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。 二、添加依赖 < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-amqp </ artifactId > </ dependency > 三、添加配置文件创建消息队列 @Configuration public class MessageConfig { public final static String EMAIL_QUEUE_NAME = "emailQueue" ; @Bean public Queue emailQueue ( ) { //队列名，是否持久化 return new Queue ( EMAIL_QUEUE_NAME , true ) ; } } 四、创建消息队列发送者 下面的生产者与消费者是我用来一步发送邮件的 @Service public class MessageSender { public Logger logger =