薛定谔的汪

前言在使用 RabbitMQ 的时候，可以通过消息持久化操作来解决因为服务器宕机而导致消息丢失，保证了消息的可靠性。但还有个问题，当消息的生产者将消息发送出去后，消息到底有没有正确地到达服务器呢？如果不进行特殊配置，默认情况下消息的发送情况是不会返回给生产者的，也就是生产者默认情况下是不知道消息到底有没有发送到 RabbitMQ Server，如果在消息到达前就丢失了（比如因为网络原因），持...

前言前面学到 direct 类型的交换器路由规则是完全匹配 BindingKey 和 RoutingKey，但是这种严格的匹配方式在很多情况下不能满足实际业务需求，RabbitMQ 提供了一种 topic 模型可以灵活组配路由和绑定。 模型 topic 类型的交换器在匹配规则上进行了扩展，它与 direct 类型相似，也是将消息路又道 BindingKey 和 RountingKey 相匹...

上篇学习总结了 RabbitMQ 的 sub/pub 模式，今天接着学习它的 Routing 模式。此模式使用了“direct”类型的 Exchange。 模型 解读队列一的 BindingKey 是“error”，队列二的BindingKey 是“info”、“error”和“warning”，Exchange 的类型是 direct，当 RoutingKey 是 error ...

今天来学习下 RabbitMQ 的消息订阅发布模式：pub/sub。 概念发布订阅模式：一个生产者发布消息，多个消费者订阅该生产者，这样同一条消息可以被多个消费者消费。 模型 解读 一个生产者，多个消费者。 每个消费者都有自己的队列。 每个队列都绑定到交换器上。 生产者不是直接把消息发送到队列，而是发到了图中的“X”，也就是交换器（Exchange），交换器根据相应的路由绑定到...

前言昨天在学习 RabbitMQ 的公平分发机制时提到了ack 应答机制，代码如下： 12boolean autoAck = false;channel.basicConsume(QUEUE_NAME,autoAck,consumer); 应答 ackRabbitMQ 有两种应答模式，自动和手动。 分别对应 autoAck 为 true 何 false。 自动应答autoAck = tru...

前言上一篇我们学习了 RabbitMQ 的轮询调度机制，把消息平均分配给消费者去消费，而不管消费者消费消息的能力，因为对于消息队列 RabbitMQ 来说，它是不知道消费者消费消息的能力的。 现在我们想根据消费者消费消息的能力来分配消息，即”能者多劳“。比如 Recv1 消费者它收到消息后处理业务的时间是1秒，Recv2 消费者它收到消息后处理业务的时间是2秒，很明显 Recv1 消费消息的...

上篇学习了 RabbitMQ 的简单队列，它是“一对一”的。但是如果想实现多个消费者监听同一个队列的话，简单队列就不满足要求了。

RabbitMQ 提供了另外一种队列来满足上述需求—-工作队列：Work Queues，它有两种模式：轮询和公平分发。今天学习总结 RabbitMQ 工作队列的轮询方式。

RabbitMQ中的消息都只能存储在Queue中，生产者（下图中的P）生产消息并最终投递到Queue中，消费者（下图中的C）可以从Queue中获取消息并消费。这就是简单队列。 我是利用 SpringBoot 来进行测试，因为 SpringBoot 已经集成 RabbitMQ 所需 jar 包，直接新建一个 SpringBoot 项目然后引入依赖即可： 123456<!-- http...

本文对rabbitmq基础介绍，完全是为了下一篇rabbitmq性能测试做准备，让读者去了解我们需要测试的是什么样一个“东西”。 引言你是否遇到过两个（多个）系统间需要通过定时任务来同步某些数据？你是否在为异构系统的不同进程间相互调用、通讯的问题而苦恼、挣扎？如果是，那么恭喜你，消息服务让你可以很轻松地解决这些问题。消息服务擅长于解决多系统、异构系统间的数据交换（消息通知/通讯...

今天来学习RabbitMQ 的 vhost 和用户的概念。