calm_encode的博客

一 引入的POM依赖 <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>3.6.5</version> </dependency> 二 声明队列的源码 package com.rabbitmq.client; public interface C

一 概述 RocketMQ主要是由Producer，Broker，Consumer三部分组成，其中Producer负责生产消息，Consumer负责消费消息，Broker负责存储消息。 Broker在实际部署过程中对应一台服务器，每个Broker可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的Broker。 Message Queue用于存储消息的物理地址，每个Topic中的消息地址存储于多个Message Queue中。 ...

一 概述 RabbitMQ的主要使用场景： 二 回顾基本知识 消息代理：可以理解为安装消息中间件的服务器。当消息发送者发送消息之后，这些消息将会由消息代理进行管理，消息代理保证消息能够传递到指定的目的地。 消息队列中主要的消息目的地： 1. 点对点消息通信：消息发送者发送消息，消息代理将其放入队列中，消息接收者从队列中获取消息内容，消息读取后被一处队列。消息的发送者是唯一的，但是消息接收者并不唯一。 ...

一 概述 RabbitMQ管理页面的使用总结。 二 参考 觉得这篇文档讲的非常不错，先参考一下，等有新的了解再来补充： RabbitMQ 管理页面该如何使用 (qq.com)https://mp.weixin.qq.com/s/N7VaBLqri5ZOPy8nCawuzQ 待续... ...

一 概述 对于RabbitMQ中被删除的消息是真的被删除了吗，答案是：NO；被删除的消息去往何方就涉及到了死信队列。 二 死信交换机 死信交换机，Dead-Letter-Exchange 简称DLX。它是用来接收死信消息（Dead Mesasge）。成为死信消息的情况： 消息被拒绝。 消息过期。 消息队列中的消息已经达到最大长度。 当队列中的消息变成死信消息之后，就会被发送到DLX，而绑定DLX的消息队列则为死信队列。 DLX本质上也是一个普通的交换机，我可以为...

一 概述 在RabbitMQ中，默认情况下，消息在没有设置消息过期的参数的时候是不会过期的，即使消息没有被消费掉，消息会一直存储在队列中。 二 队列消息存活时间TTL TTL(Time-To-Live)，消息存活的时间，即消息的有效期。我们可以通过设置TTL来实现消息有一个存活时间的需求。当这个消息的存活时间超过了TTL并且还没有被消费，那么该消息就会变成死信。 TTL的设置： 1. 在我们声明队列时，在属性中进行消息有效期设置，这...

一 概述 关于排他性，如果设置为 排他性，则该消息队列只有创建它的 Connection 才能访问，其他的 Connection 都不能访问该消息队列，如果试图在不同的连接中重新声明或者访问排他性队列，那么系统会报一个资源被锁定的错误。另一方面，对于排他性队列而言，当连接断掉的时候，该消息队列也会自动删除（无论该队列是否被声明为持久性队列都会被删除）。 待续。。。 ...

一 概述 生产者发送消息后，这个消息的确认对于MQ来说，MQ会拥有自己的确认模式来完成。 二 RabbitMQ的消息确认模式 当我们发送消息后，服务端如何知道消息已经被消费。 模式1：自动模式，不管消费者获取到消息之后是否是成功处理消息，服务端都认为成功的。 模式2：手动模式，消费者获取到消息之后，服务器会将消息标记为不可用，等待消费者反馈，如果不反馈，则一直标记为不可用。 ...

一 概述 RabbitMQ不同账号的级别 超级管理员administrator，可以登录控制台，查看所有信息，可以对用户和策略进行操作。 监控者monitoring，可以登录控制台，可以查看节点的相关信息，比如进程数，内存磁盘使用情况。 策略制定者policymaker，可以登录控制台，指定策略，但是无法查看节点信息。 普通管理员management仅能登录控制台。 其他，无法登录控制台，一般指的时提供者和消费者。 RabbitMQ使用guest用户登录具有最高权限。 二 RabbitMQ命令

一 概述 Apache RocketMQ是一个采用java语言开发的分布式的消息系统。 二 RocketMQ核心概念介绍 Producer：消息生产者，负责产生消息，一般由业务系统负责产生消息。 Producer group：一类producer的集合，这类producer通常发送一类消息，并发送逻辑一致。 Consumer：消费者，负责消费消息，一般是由后台系统负责异步消费。 Push consumer：服务端向消费者推送消息。 Pull consumer：消费者向服务定时...