前言 新公司项目使用的消息队列是RabbitMQ,之前其实没有在实际项目上用过RabbitMQ,所以对它的了解都谈不上入门.趁着周末休息的时间也猛补习了一波,写了两个窗体应用,一个消息发布端和消息消费端.园子里解释RabbitMQ基础的很多了,这里就不对RabbitMQ的基础再做叙述了,来点实际工作中一定会碰到的问题和解决的方案. RabbitMQ 消息发布确认机制 默认情况下消息发布端执行BasicPublish方法后,消息是否到达指定的队列的结果发布端是未知的.BasicPublish方法的

最近起了个项目消息中心,用来中转各个系统中产生的消息,用到的是RabbitMQ,由于UAT环境.生产环境每台消费者服务都是多台,有些消息要求按顺序消费,所以需要采取一定的措施保证消息的顺序消费,下面讲下我们不断优化的三种方法: 1.我们最开始考虑的比较简单,采用的direct交换机,指定特定消费者服务器监听队列,其他消费者服务器不监听.比如现在有C1.C2.C3三台消费者机器,我们决定C1消费消息,C2.C3不监听.我们在启动C1的时候,启动脚本中添加C1_IP,在代码中做处理,消费者服务器启动

RabbitMQ 的优化 channel prefetch Count 死信队列 什么是死信队列 使用场景 代码实现 延迟队列 什么是延迟队列 使用场景 实现延迟队列的方式 Queue TTL Message TTL 使用 Queue TTL 设置过期时间 使用 Message TTL 设置过期时间 使用插件还是Queue TTL处理延迟队列呢? 参考 RabbitMQ 的优化 channel 生产者,消费者和 RabbitMQ 都会建立连接.为了避免建立过多的 TCP 连接,减少资源额消耗.

前提 在某一次用户标签服务中大量用到异步流程,使用了RabbitMQ进行解耦.其中,为了提高消费者的处理效率针对了不同节点任务的消费者线程数和prefetch_count参数都做了调整和测试,得到一个相对合理的组合.这里深入分析一下prefetch_count参数在RabbitMQ中的作用. prefetch_count参数的含义 先从AMQP(Advanced Message Queuing Protocol,即高级消息队列协议,RabbitMQ实现了此协议的0-9-1版本的大部分内容)和Ra

从AMQP协议可以看出,MessageQueue.Exchange和Binding构成了AMQP协议的核心,下面我们就围绕这三个主要组件    从应用使用的角度全面的介绍如何利用Rabbit MQ构建消息队列以及使用过程中的注意事项. 1. 声明MessageQueue 在Rabbit MQ中,无论是生产者发送消息还是消费者接受消息,都首先需要声明一个MessageQueue.这就存在一个问题,是生产者声明还是消费者声明呢?要解决这个问题,首先需要明确: a)消费者是无法订阅或者获取不存在的Me

RabbitMQ中RPC的实现:客户端发送请求消息,服务端回复响应消息,为了接受响应response,客户端需要发送一个回调队列的地址来接受响应,每条消息在发送的时候会带上一个唯一的correlation_id,相应的服务端处理计算后会将结果返回到对应的correlation_id. RPC调用流程: 当生产者启动时,它会创建一个匿名的独占回调队列,对于一个RPC请求,生产者发送一条具有两个属性的消息:reply_to(回调队列),correlation_id(每个请求的唯一值),请求被发送到r

rabbitmq作为消息队列可以有消息消费确认机制,之前写个基于redis的通用生产者 消费者 并发框架,redis的list结构可以简单充当消息队列,但不具备消费确认机制,随意关停程序,会丢失一部分正在程序中处理但还没执行完的消息.基于redis的与基于rabbitmq相比对消息消费速度和消息数量没有天然的支持. 使用rabbitmq的最常用库pika 不管是写代码还是运行起来都比celery使用更简单,基本能够满足绝大多数场景使用,用来取代celery  worker模式(celery有三个

A. 多线程消费同一队列 参考资料:https://www.rabbitmq.com/tutorials/tutorial-two-java.html 消费一条消息往往比产生一条消息慢很多,为了防止消息积压,一般需要开启多个工作线程同时消费消息.在 RabbitMQ 中,我们可以创建多个 Consumer 消费同一队列.示意图如下: gordon.study.rabbitmq.workqueue.Sender.java public class Sender { private static f

如果是高并发下,rabbitmq服务器上收到成千上万条消息,那么当打开消费端时,这些消息必定喷涌而来,导致消费端消费不过来甚至挂掉都有可能. 在非自动确认的模式下,可以采用限流模式,rabbitmq 提供了服务质量保障qos机制来控制一次消费消息数量. 下面直接上代码: 生产端: package com.zxy.demo.rabbitmq; import java.io.IOException; import java.util.concurrent.TimeoutException; impo

​ 从RabbitMQ 3.6.0之后,有了 Lazy Queues 的概念-一个会尽早的将队列中的内容移动到磁盘的队列,并且只有当消费者需要的时候,才会将它们加载到内存中 ​ 惰性队列设计的一个主要的目的就是去支持非常长的队列(上亿级).队列可能会变的非常长因为各种各样的原因: 消费者离线/宕机/停机维护 大量的请求突然涌入,生产者正在超过消费者 消费速度低于正常情况 ​ 默认情况下,当消息发送到RabbitMQ时,会被存储在内存中,这样做的主要目的是为了消息能尽快的发送给消费者.即使是持久化

在声明交换器和队列时,有一个属性叫autoDelete,表示是否自动删除. 如果autoDelete=true,表示自动删除.此处我们要理解,自动删除的条件是什么? 这里的关键是,自动删除的条件是向后的. RabbitMQ的整个消息流是,生产端发布消息和routingKey,经由交换器,依据routingKey,到达指定队列.队列推送消息到已经订阅此消息的消费者.  再来解释"自动删除的条件是向后的"这句话. 对于exchange交换器,向前是生产端发布的消息和routingKey,这

MyDisruptor V2版本介绍 在v1版本的MyDisruptor实现单生产者.单消费者功能后.按照计划,v2版本的MyDisruptor需要支持多消费者和允许设置消费者组间的依赖关系. 由于该文属于系列博客的一部分,需要先对之前的博客内容有所了解才能更好地理解本篇博客 v1版本博客:从零开始实现lmax-Disruptor队列(一)RingBuffer与单生产者.单消费者工作原理解析 MyDisruptor支持多消费者 disruptor中的生产者和消费者是互相制约的,生产者的生产速度不

上一节说了这么多废话,看也看烦了,现在我们就来用鼠标点点点,来简单玩一下这个RabbitMQ. 注意:这一节还是不用敲什么代码,因为上一节我们设置了那个可视化工具,我们先用用可视化工具熟悉一下流程. 打开可视化页面,http://localhost:15672 顺便说一下RabbitMQ中的持持久化:这里持久化分为三种:消息持久化,交换器持久化,队列持久化... 举个例子,就简单说说交换器持久化,其实就是为了防止将消息发到交换器了,但是RabbitMQ服务器突然暴毙,没用了,那数据不就丧失了么?

1.RPC简述 RPC,Remote Procedure Call 远程过程调用.通俗讲,两段程序不在同一个内存空间,无法直接通过方法名调用,就需要通过网络通信方式调用.对于RabbitMQ,本身就是用于消息通信.简单的RabbitMQ是,生产端发送消息,经由交换器,到达队列.消费端不需要知道生产端,消费端订阅队列,消费队列中的消息.而对于RPC,希望消费端消费消息后,返回一个结果,结果经由网络,再返回给生产端. 不考虑RabbitMQ针对RPC的特有设计.最简单的设计是,生产端和消费端共同约定

RabbitMQ是一款使用Erlang开发的开源消息队列.本文假设读者对RabbitMQ是什么已经有了基本的了解,如果你还不知道它是什么以及可以用来做什么,建议先从官网的 RabbitMQ Tutorials 入门教程开始学习. 本文将会讲解如何使用RabbitMQ实现延时重试和失败消息队列,实现可靠的消息消费,消费失败后,自动延时将消息重新投递,当达到一定的重试次数后,将消息投递到失败消息队列,等待人工介入处理.在这里我会带领大家一步一步的实现一个带有失败重试功能的发布订阅组件,使用该组件后可

继续上篇文章解决RabbitMQ消息丢失问题和保证消息可靠性(一) 未完成部分,我们聊聊MQ Server端的高可用和消费端如何保证消息不丢的问题? 回归上篇的内容,我们知道消息从生产端到服务端,为了保证消息不丢,我们必须做哪些事情? 发送端采用Confirm模式,注意Server端没成功通知发送端,需要重发操作需要额外处理 消息的持久化处理 上面两个操作保证消息到服务端不丢,但是非高可用状态,如果节点挂掉,服务暂时不可用,需要重启后,消息恢复,消息不会丢失,因为有磁盘存储. 本文先从消费端讲起

理解Confirm消息确认机制: 消息的确认,是指生产者投递消息后,如果Broker收到消息,则会给我们生产这一个应答. 生产者进行接收应答,用来确定这条消息是否正常的发送到Broker,这种方式也是消息的可靠性投递的核心保障. 如何实现Confirm确认消息? 第一步:在channel上开启确认模式:channel.confirmSelect() 第二步:在channel上添加监听:addConfirmListener,监听成功和失败的返回结果, 根据具体的结果对消息进行重新发送.或者记录日志

Binding:绑定,Exchange和Exchange.Queue之间的连接关系 Binding中可以包含RoutingKey或者参数 Queue:消息队列,实际存储消息数据 Durability:是否持久化,Durable:是,Transient:否 Auto Delete:如选yes,代表当最后一个监听被移除之后,该Queue会自动被删除 Message:服务器和应用程序之间传送的数据 本质上是一段数据,有Properties和Payload(Body)组成 常用属性:delivery m

前提 之前有个打算在学习RabbitMQ之前,把AMQP详细阅读一次,挑出里面的重点内容.后来找了下RabbitMQ的官方文档,发现了有一篇文档专门介绍了RabbitMQ中实现的AMQP模型部分,于是直接基于此文档和个人理解写下这篇文章. AMQP协议 AMQP全称是Advanced Message Queuing Protocol,它是一个(分布式)消息传递协议,使用和符合此协议的客户端能够基于使用和符合此协议的消息传递中间件代理(Broker,也就是经纪人,个人感觉叫代理合口一些)进行通信.

知识储备: 交换机: ​ RabbitMQ中有4中交换机,分别是 (FANOUT)扇形交换机: 扇形交换机是最基本的交换机类型,它所能做的事情非常简单---广播消息.扇形交换机会把能接收到的消息全部发送给绑定在自己身上的队列.因为广播不需要"思考",所以扇形交换机处理消息的速度也是所有的交换机类型里面最快的. (DIRECT)直连交换机 直连交换机是一种带路由功能的交换机,一个队列会和一个交换机绑定,除此之外再绑定一个routing_key,当消息被发送的时候,需要指定一个bindin

RabbitMQ 如何做分布式 前言 集群配置方案 cluster 普通模式 镜像模式 federation shovel 节点类型 RAM node Disk node 集群的搭建 1.局域网配置 2.每台及其中安装 RabbitMQ 3.设置不同节点间同一认证的Erlang Cookie 4.使用 -detached运行各节点 5.将节点加入到集群中 6.查看集群状态 参考 RabbitMQ 如何做分布式 前言 前面几篇文章介绍了消息队列中遇到的问题,这篇来聊聊 RabbitMQ 的集群搭建