
RabbitMQ
文章平均质量分 77
MrDJun
热爱学习,传递知识。
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
消息中间件 - 惰性队列
一、什么是惰性队列 惰性队列会尽可能的将任何消息存入磁盘,这样可以减少了内存的消耗,当消费者消费到相应的消息时才会被加载到内存,会增加I/O的使用。下面看一组100万数据的内存开销: 在发送 1 百万条消息,每条消息大概占 1KB 的情况下,普通队列占用内存是 1.2GB,而惰性队列仅仅占用 1.5MB 。二、应用场景(1)支持存储大量消息的长队列。(2)消息大量积压的时候,消费速度太慢,到了消息大爆发的时候,MQ服务器会撑不住,机会影响其它队列的消息收发。那么消息就可以写入磁盘,需要原创 2021-08-25 22:34:47 · 301 阅读 · 0 评论 -
消息中间件 - 优先级队列
在优先级队列中,针对生产者给消息设置的优先级进行排序,优先级越大的越先被消费者消费。如果在消费者的消费速度大于生产者的速度,且Broker中没有消息堆积的情况下,对发送的消息设置优先级没有意义。在生产者,按如下方式给消息设置 priority 属性AMQP.BasicProperties properties = new AMQP.BasicProperties().builder() // 设置当前消息的优先级 .priority(5).build(原创 2021-08-25 22:31:29 · 692 阅读 · 0 评论 -
消息中间件 - RabbitMQ备份交换机
通过消息回退机制和mandatory参数,可以处理交换机投递失败的消息。 消息回退到生产者后,有时候并不知道该如何处理这些无法路由的消息,最多就是打个日志,存到缓存定时投递,超出投递失败次数进行报警,再手动处理,手动的通病就是麻烦易出错。此外,生产者不止一台机器,那么每台都需要写处理这些回退消息的逻辑代码,反而增加了生产者的复杂性。那么既不丢失消息,又不增加生产者的复杂性,该怎么做? 可以为队列设置死信交换机来存储投递失败的消息,可是这些不可路由消息根本没有机会进入到队列,因此无法使原创 2021-08-25 22:30:38 · 424 阅读 · 0 评论 -
消息中间件 - RabbitMQ消息的发布确认(高级)
一、确认机制方案 在生产环境中由于一些不明原因,导致rabbitmq重启,在RabbitMQ重启期间生产者消息投递失败,导致消息丢失,需要手动处理和恢复。于是,我们开始思考,如何才能进行RabbitMQ的消息可靠投递呢?特别是在这样比较极端的情况,RabbitMQ集群不可用的时候,无法投递的消息该如何处理呢?应用[xxx]在[08-1516:36:04]发生[错误日志异常],alertId=[xxx]。由[org.springframework.amqp.rabbit.listener.Blocki原创 2021-08-25 22:29:42 · 1739 阅读 · 0 评论 -
消息中间件 - RabbitMQ延迟队列
一、概念 延时队列的内部是有序的,最重要的特性就体现在它的延时属性上,延时队列中的元素是希望在指定时间到了以后或之前取出和处理,简单来说,延时队列就是用来存放需要在指定时间被处理的元素的队列。二、应用场景订单在十分钟之内未支付则自动取消。新创建的店铺,如果在十天内都没有上传过商品,则自动发送消息提醒。用户注册成功后,如果三天内没有登陆则进行短信提醒。用户发起退款,如果三天内没有得到处理则通知相关运营人员。预定会议后,需要在预定的时间点前十分钟通知各个与会人员参加会议原创 2021-08-25 22:05:41 · 506 阅读 · 0 评论 -
消息中间件 - 死信队列
一、死信的概念 死信,顾名思义就是无法被消费的消息,字面意思可以这样理解,一般来说,producer 将消息投递到 broker 或者直接到 queue 里了,consumer 从 queue 取出消息进行消费,但某些时候由于特定的原因导致 queue 中的某些消息无法被消费,这样的消息如果没有后续的处理,就变成了死信,有死信自然就有了死信队列。 应用场景:为了保证订单业务的消息数据不丢失,需要使用到 RabbitMQ 的死信队列机制,当消息消费发生异常时,将消息投入死信队列中。还有比如说:用户原创 2021-08-24 23:05:34 · 449 阅读 · 0 评论 -
消息中间件 - RabbitMQ消息的发布确认(初级)
场景描述:消息持久化是指消息保存在磁盘上,如果消息还没来得及写入磁盘就发生宕机,那么消息一样会发生丢失。解决方案:生产者发送消息的到了所有匹配的队列之后,队列写入磁盘成功后再回复生产者。如何100%确保消息不丢失?做好这三步,消息才能绝对不丢失:①队列持久化②队列中的消息持久化③发布确认一、发布确认原理 生产者将信道设置成 confirm 模式,一旦信道进入 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始),一旦消息被投递到所有匹配的队列之原创 2021-08-24 23:04:49 · 293 阅读 · 0 评论 -
消息中间件 - RabbitMQ不公平分发
在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮询分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者 1 处理任务的速度非常快,而另外一个消费者 2 处理速度却很慢,这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是RabbitMQ 并不知道这种情况它依然很公平的进行分发。为了避免上述情况,强烈建议使用不公平分发(能者多劳),生产者和消费者都需要原创 2021-08-24 23:04:19 · 1006 阅读 · 0 评论 -
消息中间件 - RabbitMQ消息持久化
手动ACK应答可以处理任务不丢失的情况,但是如何保障当 RabbitMQ 服务停掉以后消息生产者发送过来的消息不丢失?默认情况下 RabbitMQ 退出或由于某种原因崩溃时,它忽视队列和消息,除非告知它不要这样做。确保消息不会丢失需要做两件事:需要将队列和消息都标记为持久化。本章节实现简单的队列和消息的持久化功能,更加强有力的持久化策略,在后面发布确认章节再详述。队列持久化生产者和消费者的信道都需要将下面的 queueDeclare() 方法的 durable 属性设置值为 true。在com.r原创 2021-08-24 23:03:37 · 250 阅读 · 0 评论 -
消息中间件 - RabbitMQ 消息应答
一、场景 消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了,会发生什么情况?RabbitMQ 一旦向消费者传递了一条消息,便立即将该消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费这的消息,因为它无法接收到。为了保证消息在发送过程中不丢失,rabbitmq 引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 rabbitmq 它已经处理了,rabbitmq 可以把该消息删除了。原创 2021-08-24 23:03:07 · 284 阅读 · 0 评论 -
消息中间件 - RabbitMQ 六种模式
官网链接简单模式,work模式,Publish/Subscribe发布与订阅模式,Routing路由模式,Topics主题模式,RPC远程调用模式(远程调用,不太算MQ;不作介绍);第一、简单模式(Simple)public class SimpleProducer { String SIMPLE_QUEUE_NAME = "hello"; public static void main(String[] args) throws Exception { Conne原创 2021-08-24 23:02:17 · 1032 阅读 · 0 评论 -
消息中间件 - RabbitMQ 四大核心概念
生产者,交换机,队列,消费者。四大核心类似于以下的协同关系。四大核心的相互关联。生产者产生数据发送消息的程序是生产者交换机交换机是 RabbitMQ 非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息,是将这些消息推送到特定队列还是推送到多个队列,亦或者是把消息丢弃,这个得有交换机类型决定。队列队列是 RabbitMQ 内部使用的一种数据结构,尽管消息流经 RabbitMQ 和应用程序,但它们只能存储在队列中。队列仅受主原创 2021-08-24 22:59:23 · 429 阅读 · 0 评论 -
消息中间件 - RabbitMQ 安装
RabbitMQ官网安装RabbitMQdocker run -d --restart=always -p 5672:5672 -p 15672:15672 --name rabbitmq -v ${RABBITMQ_DIR}/data:/mydata/rabbitmq -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:management访问 ip:15672(如 127.0.0.1:15672)[外链原创 2021-08-24 22:57:42 · 184 阅读 · 0 评论 -
消息中间件 - MQ的分类
1、ActiveMQ优点单机吞吐量万级,时效性ms级,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据。缺点官方社区现在对ActiveMQ 5.x维护越来越少,高吞吐量场景较少使用。2、Kafka大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被LinkedIn,Uber, Twitter, Netflix等大公司所原创 2021-08-24 22:57:06 · 255 阅读 · 0 评论 -
消息中间件 - MQ的相关概念
什么是MQ?MQ(messagequeue),从字面意思上看,本质是个队列,FIFO先入先出,只不过队列中存放的内容是message而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。消息中间件接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹时,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑消息中间件就是一个快递站,一个快原创 2021-08-24 22:56:25 · 232 阅读 · 0 评论 -
缓存击穿、穿透、雪崩的问题及解决
缓存击穿、穿透、雪崩的问题及解决一、缓存穿透(查询一个永不存在的数据)当查询一个一定不存在的数据时,由于缓存是不命中,将去查询数据库,但是数据库也无此记录,我们没有将这次查询的null写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。例如:需要查询11号商品,假设缓存中没有11号商品,100万的并发进来之后,同时判断都没有,那么这100万就都会到数据库去查11号商品,相当于缓存根本没用上,导致数据库压力增大甚至崩溃宕机。风险:利用不存在的数据进行攻击,数据库瞬时原创 2021-01-30 21:16:42 · 222 阅读 · 0 评论 -
RabbitMQ 基础概念的理解
预计阅读时间:12分钟本文文字虽多,字字浓缩,静下心来,学习需要沉淀。目录直通车一、程序中为什么要用MQTT?二、MQTT是什么?1、Qos(确保消息送达)2、LWT(临终遗嘱)三、关于RabbitMQ1、拍RabbitMQ的“马屁”(1)自带“光环”(2)是实现了AMQP标准的消息服务器(3)R...原创 2019-07-22 17:27:09 · 701 阅读 · 0 评论