bug_null的博客

Firehose默认情况下处于关闭状态，并且Firehose的状态是非持久化的，会在RabbitMQ服务重启的时候还原成默认的状态。Firehose开启之后会影响RabbitMQ整体服务性能，因为它会引起额外的消息生成、路由和存储。在RabbitMQ中可以使用Firehose实现消息的跟踪，Firehose可以记录每一次发送或者消息的记录，方便RabbitMQ的使用都进行调试、排错等。分别对应生产者投递到交换器的消息和消费者从队列中获取的消息。的交换器，按收到交换器的名称加上一个前缀变更。

以经典的转账为例，为了保证不重复扣款或者重复加钱，系统维护一张资金变动表，这个表里至少需要记录交易单号、变动账户、变动金额等字段，使用交换单号和变动账号做联合唯一索引（单号一般由上游系统生成保证唯一性）这样如果同一笔交易发生重复请求时就会直接报索引冲突，事务直接回滚，现实中数据库唯一索引的方法通常做为兜底的保证；否则执行正常的更新余额的动作。一个幂等操作的特点是，其任意多次执行所产生的影响均与一次执行的影响相同。一个幂等的方法，使用同样的参数，对它进行多次调用和一次调用，对系统产生的影响是一样的。

在消费慢的时候可以设置Qos的prefetchCount，它表示broker在向消费者发送消息的时候，一旦发送了prefetchCount个消息而没有一个消息确认的时候，就停止发送。消息中间件本身是具备一定的缓冲能力的，但这个能力是有容量限制的，如果长期运行并没有任何处理，最终会导致Broker崩溃，而分布式系统的故障往往会发生上下游传递，连锁反应可能会引起系统大范围的宕机，这就很悲剧了。如果设置了multiple为true，消费者在确认的时候，比如说id是8的消息确认了，则在8之前的所有消息都确认了。

可以保证数据成功的发送到RabbitMQ，以及持久化机制，然尔这依然无法完全保证整个过程的可靠性，因为如果消息被消费过程中业务处理失败了，但是消息却已经被标记为消费了，如果又没有任何重度机制，那结果基本等于丢消息。由于消息被不断的重新放回队列，而消费者又只有当前这一个，所以，在不断拒收中被放回。从观察到的结果也印证了，反复的被推送，接收的一个过程中，使用命令查看队列的一个消费的情况。通过观察发现，消息已经没有在队列中了，那就是消息已经被丢弃了。在浏览器中访问，同样有66%的概率会被拒绝，仅33%会被确认。

RabbitMQ通过配制queue_index_embed_msgs_below可以根据消息大小决定存储位置，默认queue_index_embed_msgs_below是4096字节(包含消息体、属性及headers)，小于该值的消息都存在rabbit_queue_index中。在重启之后，非持久化的消息队列已经没有了，而定义为持久化的消息交换器、队列和消息都还是存在的。这里存在两个队列，一个是持久化的队列, 一个是非持久化的消息队列。在文件内容中，还有检查到发送的数据内容: hello world。

rabbitmq-常用命令使用

​ RabbitMQ后来引入了一种轻量级的方式，叫发送方确认(publisher confirm)机制，生产者将信息设置成confirm（确认）模式，一旦信道进入了confirm模式，所有在该信道上面发送的消息都会被指派成一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后（如果消息和队列是持久化的，那么消息会在消息持久化后发出），RabbitMQ就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一的ID），这样生产者就知道消息已经正确送达了。

引入SpringBoot的父类</</</</maven的导入</</</</</</</</</</</</</</

maven导入</</</</提示：ConnectionFactory有三个实现CachingConnectionFactory 基于channel的缓存模式 最常用是这个。LocalizedQueueConnectionFactory 直接连接某个节点的方式。如果是集群，此种不太适合。SimpleRoutingConnectionFactory 在当前的连接工厂中按查找的KEY获取连接工厂。运行消息的生产者，查看消息发送信息通过检查发现，消息已经成功的发送到了队列运行主程序,检查控制台的输出。

当启动消费者后，便可获取到发送至队列的消息。经过检查确认，发现消息已经被消费了。至此拉模式的消费者完成。

除消息外，还提供了Channel这个对象，通过channel可以有更大的灵活性。再观察消息者，便能看到消费者队列中已经收到了发送的消息。这样监听者就会处于监听状态。普通的场景基本够用。在推模式中消息的即时性比拉模式会好。再启动生产者，向队列中发送消息。

Spring-amqp是对AMQP的一些概念的一些抽象，Spring-rabbit是对RabbitMQ操作的封装实现。主要有几个核心类等类完成对Exchange、Queue、Binding的操作，在容器中管理 了类的时候，可以对Exchange、Queue、Binding进行自动声明。类是发送和接收消息的工具类。是消费消息的容器。目前一些比较新的项目会使用基于注解的方式，而比较老的一些项目可能还是基于配制文件的方式。

top类型的交换器背后原理跟direct类型类似只要队列的bingingkey的值与消息的routingKey的匹配，队列就可以收到该消息。使用topic类型的交换器，队列绑定到交换器、bingingKey时使用通配符，交换器将消息路由转发到具体队列时，会根据消息routingKey模糊匹配，比较灵活。使用topic类型的交换器, routingKey就不能随便写了，它必须是点分单词，单词可以随便写，一般按消息的特征，该点分单词字符串最长255字节。观察可以发现，此队列与消息的绑定已经成功。

官方文档参考：https://www.rabbitmq.com/tutorials/tutorial-four-python.html。即按日志不同的级别，分发到不同的队列。每个队列只处理自己的对应的级别日志。类型的Exchange,发N条消息并使用不同的routingKey,消费者定义队列并将队列。完成匹配的情况下消息才会转发到对应的队列中被消费。启动消费者，查看消息通否被正常消费。ERROR的消费者控制台输出。创建WARN级别的消息者。创建ERROR的消费者。创建INFO级的消费者。

应该是追加到一个指定的队列，还是追加到多个队列，还是丢弃。每个消费者定义生成一个队列关绑定到同一个Exchange，每个消费者都可以消费完整的消息。在RabbitMQ中，生产者不是将消息直接发送给消息消息队列，实际上生产者根本不知道一个消息被发送到哪个队列。当启动生产者后，可以发现已经产生了3个默认的交换机及队列的绑定关系。交换器很简单，从名称就可以看出来（用风扇吹出去），将所有的收到的消息发给它的知道的所有队列。此样例使用的是临时队列，即消费都实现将自动创建此队列，当消费都退出后，此队列也将自动删除。

官网关于工作模式的解释地址：https://www.rabbitmq.com/getstarted.html。

当启用rabbitmq_management插件时，自动启动了依赖的rabbitmq_management_agent插件和rabbitmq_web_dispatch。RabbitMQ安装需要依赖:socat和logrotate，logrotate操作系统已经存在了，只需要安装socat就可以了。RabbitMQ的安装首先需要安装Erlang,因为它是基于Erlang的VM运行的。http://<安装RabbitMQ的机器的IP>:15672。至此RabbitMQ的安装就已经完成。登录成功后，可以看到。