<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[bug_null的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/bug_null</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; bug_null]]></copyright><item><title><![CDATA[RabbitMQ-延迟交换器]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/145116796</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/145116796</guid><author>bug_null</author><pubDate>Mon, 13 Jan 2025 15:22:06 +0800</pubDate><description><![CDATA[在之前的延迟场景中，消息放入延迟队列的时间都是相同的。通过分析可以发现，如果将消息放入延迟队列，由于延迟队列是顺序消费的特性，即按照顺序一个一个的消费。采用延迟队列是不行的。这里和TTL方式有很大的不同就是TTL存放的是死信队列（deayquque），而这个插件存放的消息是在延迟交换器里(x-delayed-message-exchange)将插件拷贝到rabbitMQ-server的安装路径：/usr/lib/rabbitmq/lib/rabbitmq_server-3.8.5/plugins/]]></description><category></category></item><item><title><![CDATA[RabbitMQ-死信队列]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/144961055</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/144961055</guid><author>bug_null</author><pubDate>Mon, 06 Jan 2025 12:29:20 +0800</pubDate><description><![CDATA[以下单打车为例，用户在下单后，寻找附近的车辆，有一个司机接单了，但是没有在规定的时间到来，导致订单超时了。这时候平台就会再次寻找附近的车辆，下单通知附件的车辆来接你。这类的场景如果放到MQ上，能实现吗？结合之前的实现已经可以做到订单超时了，但是超时后，目前还没有办法处理，这就需要使用死信队列了。DLX，全称Dead-Letter-Exchange，死信交换器。消息在一个队列中变成死信（Dead Letter）之后，被重新发送到一个特殊的交换器（DLX）中，同时DLX的队列就称为“死信队列”。]]></description><category></category></item><item><title><![CDATA[RabbitMQ-TTL机制]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/144810576</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/144810576</guid><author>bug_null</author><pubDate>Sun, 29 Dec 2024 21:08:07 +0800</pubDate><description><![CDATA[如果两种方法一起使用，则消息的TTL以两者之间较小数值为准，通常来说，消息在队列中的生存时间一旦超过设置的TTL值时，就会变更“死信（Dead Message）”，消费者默认就无法再收到该消息。当然，“死信”也是可以被取出来消费的。经过操作后可以发现，此消息队列中的消息存活了10秒，然后消息就被清空了，由于队列的存活时间设置为20秒，没有消费者，所以经过了20秒后，队列就被清空了。在支付类的场景中，创建订单成功后，一般会给30分钟左右的等待时间，如果在这段时间内用户没有支付，则默认订单取消。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制7--可靠性分析-rabbitmq_tracing插件]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/144634123</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/144634123</guid><author>bug_null</author><pubDate>Sat, 21 Dec 2024 18:05:34 +0800</pubDate><description><![CDATA[rabbitmq_tracing插件相当于Firehose的GUI版本，它同样能跟踪RabbitMQ中消息的注入流出情况。rabbitmq_tracing插件同样会对流入流出的消息进行封装，然后将封装后的消息日志存入相应的trace文件中。这两个临时队列，在追溯停止后，也将不存在了。可以直接通过网页端进行查看。连接用户名和密码，按创建的用户名管密码，这里填充:root/123456。分别添加生产者的追溯和消费都的追溯,然后分别运行生产者和消费者。pattern: 消费的消息: deliver.]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制6--可靠性分析]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/144177273</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/144177273</guid><author>bug_null</author><pubDate>Sun, 01 Dec 2024 23:36:26 +0800</pubDate><description><![CDATA[Firehose默认情况下处于关闭状态，并且Firehose的状态是非持久化的，会在RabbitMQ服务重启的时候还原成默认的状态。Firehose开启之后会影响RabbitMQ整体服务性能，因为它会引起额外的消息生成、路由和存储。在RabbitMQ中可以使用Firehose实现消息的跟踪，Firehose可以记录每一次发送或者消息的记录，方便RabbitMQ的使用都进行调试、排错等。分别对应生产者投递到交换器的消息和消费者从队列中获取的消息。的交换器，按收到交换器的名称加上一个前缀变更。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制5--消息幂等性处理]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/144177253</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/144177253</guid><author>bug_null</author><pubDate>Sun, 01 Dec 2024 23:34:38 +0800</pubDate><description><![CDATA[以经典的转账为例，为了保证不重复扣款或者重复加钱，系统维护一张资金变动表，这个表里至少需要记录交易单号、变动账户、变动金额等字段，使用交换单号和变动账号做联合唯一索引（单号一般由上游系统生成保证唯一性）这样如果同一笔交易发生重复请求时就会直接报索引冲突，事务直接回滚，现实中数据库唯一索引的方法通常做为兜底的保证；否则执行正常的更新余额的动作。一个幂等操作的特点是，其任意多次执行所产生的影响均与一次执行的影响相同。一个幂等的方法，使用同样的参数，对它进行多次调用和一次调用，对系统产生的影响是一样的。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制4--消费端限流]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/143815156</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/143815156</guid><author>bug_null</author><pubDate>Sat, 16 Nov 2024 12:06:52 +0800</pubDate><description><![CDATA[在消费慢的时候可以设置Qos的prefetchCount，它表示broker在向消费者发送消息的时候，一旦发送了prefetchCount个消息而没有一个消息确认的时候，就停止发送。消息中间件本身是具备一定的缓冲能力的，但这个能力是有容量限制的，如果长期运行并没有任何处理，最终会导致Broker崩溃，而分布式系统的故障往往会发生上下游传递，连锁反应可能会引起系统大范围的宕机，这就很悲剧了。如果设置了multiple为true，消费者在确认的时候，比如说id是8的消息确认了，则在8之前的所有消息都确认了。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制3--消费端ACK机制]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/135445278</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/135445278</guid><author>bug_null</author><pubDate>Sun, 07 Jan 2024 21:28:32 +0800</pubDate><description><![CDATA[可以保证数据成功的发送到RabbitMQ，以及持久化机制，然尔这依然无法完全保证整个过程的可靠性，因为如果消息被消费过程中业务处理失败了，但是消息却已经被标记为消费了，如果又没有任何重度机制，那结果基本等于丢消息。由于消息被不断的重新放回队列，而消费者又只有当前这一个，所以，在不断拒收中被放回。从观察到的结果也印证了，反复的被推送，接收的一个过程中，使用命令查看队列的一个消费的情况。通过观察发现，消息已经没有在队列中了，那就是消息已经被丢弃了。在浏览器中访问，同样有66%的概率会被拒绝，仅33%会被确认。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制2--持久化存储机制]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/135445225</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/135445225</guid><author>bug_null</author><pubDate>Sun, 07 Jan 2024 21:26:07 +0800</pubDate><description><![CDATA[RabbitMQ通过配制queue_index_embed_msgs_below可以根据消息大小决定存储位置，默认queue_index_embed_msgs_below是4096字节(包含消息体、属性及headers)，小于该值的消息都存在rabbit_queue_index中。在重启之后，非持久化的消息队列已经没有了，而定义为持久化的消息交换器、队列和消息都还是存在的。这里存在两个队列，一个是持久化的队列, 一个是非持久化的消息队列。在文件内容中，还有检查到发送的数据内容: hello world。]]></description><category></category></item><item><title><![CDATA[RabbitMQ消息可靠性保证机制--发送端确认]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/133249693</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/133249693</guid><author>bug_null</author><pubDate>Sun, 24 Sep 2023 19:52:38 +0800</pubDate><description><![CDATA[​    RabbitMQ后来引入了一种轻量级的方式，叫发送方确认(publisher confirm)机制，生产者将信息设置成confirm（确认）模式，一旦信道进入了confirm模式，所有在该信道上面发送的消息都会被指派成一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后（如果消息和队列是持久化的，那么消息会在消息持久化后发出），RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一的ID），这样生产者就知道消息已经正确送达了。]]></description><category></category></item><item><title><![CDATA[SpringBoot整合RabbitMQ]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/133146621</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/133146621</guid><author>bug_null</author><pubDate>Thu, 21 Sep 2023 20:07:57 +0800</pubDate><description><![CDATA[引入SpringBoot的父类</</</</maven的导入</</</</</</</</</</</</</</]]></description><category></category></item><item><title><![CDATA[Spring整合RabbitMQ-注解方式]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132841720</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132841720</guid><author>bug_null</author><pubDate>Tue, 12 Sep 2023 22:09:27 +0800</pubDate><description><![CDATA[maven导入</</</</提示：ConnectionFactory有三个实现CachingConnectionFactory 基于channel的缓存模式  最常用是这个。LocalizedQueueConnectionFactory 直接连接某个节点的方式。如果是集群，此种不太适合。SimpleRoutingConnectionFactory 在当前的连接工厂中按查找的KEY获取连接工厂。运行消息的生产者，查看消息发送信息通过检查发现，消息已经成功的发送到了队列运行主程序,检查控制台的输出。]]></description><category></category></item><item><title><![CDATA[Spring整合RabbitMQ-配制文件方式-3-消息拉模式]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132701206</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132701206</guid><author>bug_null</author><pubDate>Tue, 05 Sep 2023 21:51:28 +0800</pubDate><description><![CDATA[当启动消费者后，便可获取到发送至队列的消息。经过检查确认，发现消息已经被消费了。至此拉模式的消费者完成。]]></description><category></category></item><item><title><![CDATA[Spring整合RabbitMQ-配制文件方式-2-推模式消费者]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132701185</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132701185</guid><author>bug_null</author><pubDate>Tue, 05 Sep 2023 21:49:28 +0800</pubDate><description><![CDATA[除消息外，还提供了Channel这个对象，通过channel可以有更大的灵活性。再观察消息者，便能看到消费者队列中已经收到了发送的消息。这样监听者就会处于监听状态。普通的场景基本够用。在推模式中消息的即时性比拉模式会好。再启动生产者，向队列中发送消息。]]></description><category></category></item><item><title><![CDATA[Spring整合RabbitMQ-配制文件方式-1-消息生产者]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132701041</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132701041</guid><author>bug_null</author><pubDate>Tue, 05 Sep 2023 21:46:05 +0800</pubDate><description><![CDATA[Spring-amqp是对AMQP的一些概念的一些抽象，Spring-rabbit是对RabbitMQ操作的封装实现。主要有几个核心类等类完成对Exchange、Queue、Binding的操作，在容器中管理 了类的时候，可以对Exchange、Queue、Binding进行自动声明。类是发送和接收消息的工具类。是消费消息的容器。目前一些比较新的项目会使用基于注解的方式，而比较老的一些项目可能还是基于配制文件的方式。]]></description><category></category></item><item><title><![CDATA[RabbitMQ工作模式-主题模式]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132591482</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132591482</guid><author>bug_null</author><pubDate>Wed, 30 Aug 2023 21:57:54 +0800</pubDate><description><![CDATA[top类型的交换器背后原理跟direct类型类似只要队列的bingingkey的值与消息的routingKey的匹配，队列就可以收到该消息。使用topic类型的交换器，队列绑定到交换器、bingingKey时使用通配符，交换器将消息路由转发到具体队列时，会根据消息routingKey模糊匹配，比较灵活。使用topic类型的交换器, routingKey就不能随便写了，它必须是点分单词，单词可以随便写，一般按消息的特征，该点分单词字符串最长255字节。观察可以发现，此队列与消息的绑定已经成功。]]></description><category></category></item><item><title><![CDATA[RabbitMQ工作模式-路由模式]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132591454</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132591454</guid><author>bug_null</author><pubDate>Wed, 30 Aug 2023 21:55:29 +0800</pubDate><description><![CDATA[官方文档参考：https://www.rabbitmq.com/tutorials/tutorial-four-python.html。即按日志不同的级别，分发到不同的队列。每个队列只处理自己的对应的级别日志。类型的Exchange,发N条消息并使用不同的routingKey,消费者定义队列并将队列。完成匹配的情况下消息才会转发到对应的队列中被消费。启动消费者，查看消息通否被正常消费。ERROR的消费者控制台输出。创建WARN级别的消息者。创建ERROR的消费者。创建INFO级的消费者。]]></description><category></category></item><item><title><![CDATA[RabbitMQ工作模式-发布订阅模式]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132591383</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132591383</guid><author>bug_null</author><pubDate>Wed, 30 Aug 2023 21:51:56 +0800</pubDate><description><![CDATA[应该是追加到一个指定的队列，还是追加到多个队列，还是丢弃。每个消费者定义生成一个队列关绑定到同一个Exchange，每个消费者都可以消费完整的消息。在RabbitMQ中，生产者不是将消息直接发送给消息消息队列，实际上生产者根本不知道一个消息被发送到哪个队列。当启动生产者后，可以发现已经产生了3个默认的交换机及队列的绑定关系。交换器很简单，从名称就可以看出来（用风扇吹出去），将所有的收到的消息发给它的知道的所有队列。此样例使用的是临时队列，即消费都实现将自动创建此队列，当消费都退出后，此队列也将自动删除。]]></description><category></category></item><item><title><![CDATA[RabbitMQ工作模式-工作队列]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132591116</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132591116</guid><author>bug_null</author><pubDate>Wed, 30 Aug 2023 21:37:09 +0800</pubDate><description><![CDATA[官网关于工作模式的解释地址：https://www.rabbitmq.com/getstarted.html。]]></description><category></category></item><item><title><![CDATA[RabbitMQ-常用命令]]></title><link>https://blog.youkuaiyun.com/bug_null/article/details/132512653</link><guid>https://blog.youkuaiyun.com/bug_null/article/details/132512653</guid><author>bug_null</author><pubDate>Sat, 26 Aug 2023 16:13:08 +0800</pubDate><description><![CDATA[rabbitmq-常用命令使用]]></description><category></category></item></channel></rss>