慌途L

接上一篇：RabbitMQ（四） | 惰性队列 - 解决消息堆积问题RabbitMQ的是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。在RabbitMQ的官方文档中，讲述了两种集群的配置方式：镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来代替镜像集群，底层采用Raft协议确保主从的数据一致性。普通集群，或者叫标准集群（classic cluster），具备下列特征：结构如

接上一篇：RabbitMQ（三） | 死信交换机、死信队列、TTL、延迟队列（安装DelayExchange插件）当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。解决消息堆积有两种思路：要提升队列容积，把消息保存在内存中显然是不行的。从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：而要设置一个队列为惰性队列，只需要在声明队列时

接上一篇：RabbitMQ（二） | 消息可靠性（消息确认机制、消息持久化、消息重试机制）什么是死信？当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：如果这个包含死信的队列配置了属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，检查DLX）。如图，一个消息被消费者拒绝了，变成了死信：因为simple.queue绑定了死信交换机 dl.direct，因此死信会投递给这个交换机：如果这个死信交

接上一篇：RabbitMQ（一） | MQ技术对比，以及对RabbitMQ五种消息模型的使用消息从发送，到消费者接收，会经历多个过程：其中的每一步都可能导致消息丢失，常见的丢失原因包括：针对这些问题，RabbitMQ分别给出了解决方案：RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。返回结果有两种方式：首先，修改publisher服务中的applicati

MQ，中文是消息队列（MessageQueue），字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。比较常见的MQ实现：几种常见MQ的对比：追求可用性：Kafka、 RocketMQ 、RabbitMQ追求可靠性：RabbitMQ、RocketMQ追求吞吐能力：RocketMQ、Kafka追求消息低延迟：RabbitMQ、KafkaRabbitMQ官方提供了5个不同的Demo示例，对应了不同的消息模型：建立一个父工程，包含两个SpringBoot子工程。如下图：demo工程地址：在父工程p

一、前言鉴于前面看过几个用Docker安装RabbitMQ的文章，在自己安装他们的安装教程后都会遇到的一个问题，这里我就重新再写一遍Docker安装RabbitMQ流程（内心复杂，就不能好好的让我把你们的安装教程链接分享出去吗，还要我自己来写一篇，让广大程序员避坑）。前面多数是跟别的安装教程重复的，老手可略过。二、找到对应镜像进入docker hub镜像仓库地址：https://hub.docker.com/.左上角搜索框输入rabbitMq，进入官方的镜像，可以看到以下几种类型的镜像；我们可.