MQ都得有消息模型，就会产生比如队列（Queue）、主题（Topic）、分区（Partition）这些名词，但是概念上却不尽相同。
消息的生产者将消息送到消息队列以后，由消息的消费者从消息队列中获取消息，然后进行业务逻辑的处理，消息的生产者和消费者是异步处理的，彼此不会等待阻塞，所以叫做异步架构。
可以看到，技术圈的风向一直在变，大数据、云的热度已经在慢慢消退，现在当红的是 AI 和 IoT。这些火热的概念，它最终要从论文和 PPT 落地，变成真正能解决问题的系统，否则就是一个空中楼阁。那不变的是什么？(一些题外话的感触)
RocketMQ 是笔者非常喜欢的消息队列，4.9.X 版本是目前使用最广泛的版本，但它的消费逻辑相对较重，很多同学学习起来没有头绪。
阻塞队列与普通队列的区别在于，当队列是空的时，从队列中获取元素的操作将会被阻塞，或者队列是满时，往队列里添加元素的操作会被阻塞。试图从空的阻塞队列中获取元素的线程将会被阻塞，直到其他的线程往空的队列插入新的元素。同样，试图往已满的阻塞队列中添加新元素的线程同样也会被阻塞，直到其他的线程使队列重新变得空闲起来，如从队列中移除一个或者多个元素，或者完全清空队列.
在分析阻塞队列之前我们先看生产者消费者模式，这是一个很常见的模式，生产者负责数据的生产，而消费者则负数据的消费。一般来说生产者与消费者的数量比例是m:n，该模式最大的好处就是将数据生产方与消费方进行了解耦，使得它们之间不会互相影响。为了将生产者和消费者连接起来，我们需要一个特殊的容器，该容器能存储生产者生产的数据，而消费者则能从该容器中取出数据。
在前面我们接触的队列都是非阻塞队列，比如PriorityQueue、LinkedList（LinkedList是双向链表，它实现了Dequeue接口）。
当然在剖析这几个问题之前需要简单的介绍下什么是消息队列，消息队列常见的一些基本术语和概念。
GroupName用于把多个Consumer组织到一起，相同GroupName的Consumer只消费所订阅消息的一部分。 目的:达到天然的负载均衡机制。发消息队列数要和consumer数量为倍数,才能平均负载均衡。 消费者采用负载均衡（集群模式）方式消费消息，一个分组(Group)下的多个消费者共同消费队列消息，每个消费者处理的消息不同。一个Consumer Group中的各个Consumer实例分摊去消费消息，即一条消息只会投递到一个Consumer Group下面的一个实例。例如某个Topic有3个队列，其中一个Consumer Group 有 3 个实例，那么每个实例只消费其中的1个队列。集群消费模式是消费者默认的消费方式。 集群模式： 使用相同 Group ID 的订阅者属于同一个集群。 同一个集群下的订阅者消费逻辑必须完全一致（包括 Tag 的使用） ， 这些订阅者在逻辑上可以认为是一个消费节点。
消息组接到某项目组反馈，topic 在扩容后出现部分队列无法被消费者，导致消息积压，影响线上业务？
与简单模式相比，工作队列模式(Work Queue)多了一些消费者，该模式也使用direct交换机，应用于处理消息较多的情况。特点如下：
在日常开发中，很多时候我们可能会使用队列实现异步任务的分发。例如用户下单的积分成长值增加、消息发送等等常见。这种场景可以使用Redis中的list数据类型来实现队列功能。但存在不足的几点：
Rebalance(再均衡)机制指的是：将一个Topic下的多个队列(或称之为分区)，在同一个消费者组(consumer group)下的多个消费者实例(consumer instance)之间进行重新分配。
摘要：如果Consumer端消费消息失败，那么RocketMQ是如何对失败的异常情况进行处理？ 前面两篇RocketMQ消息消费（一）/（二）篇，主要从Push/Pull两种消费模式的简要流程、长轮询机制和Consumer端负载均衡这几点内容出发，介绍了RocketMQ消息消费的正常流程和细节内容，本篇内容将主要介绍Consumer端消费失败的异常流程。 这里先回顾往期RocketMQ技术分享的篇幅： （1）消息中间件—RocketMQ的RPC通信（一） （2）消息中间件—RocketMQ的RPC通信（二） （3）消息中间件—RocketMQ消息发送 （4）消息中间件—RocketMQ消息消费（一） （5）消息中间件—RocketMQ消息消费（二）（push模式实现）
前言 在 Android多线程(一)线程池这篇文章时，当我们要创建ThreadPoolExecutor的时候需要传进来一个类型为BlockingQueue的参数，它就是阻塞队列，在这一篇文章里我们会介绍阻塞队列的定义、种类、实现原理以及应用。 1.什么是阻塞队列 阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。 BlockingQueue有两个常见阻塞场景 当队列中没有数据的情况下，消费者端的所有
上篇 https://www.jianshu.com/p/6402676abc86 文章讲解了一个定时生产消费时候消费队列里面最多有几个元素的问题。本文来探讨另外一个问题，由于生产和消费线程执行的不确定性，会产生当生产线程t1时间投递任务到队列后，消费线程可能在t1+1左右时候才会开始消费其中的一个队列，也就是生产与消费之间会有1s时间的的间隔，那么有没有办法保证生产线程t1时间投递完毕后，消费线程能在接近于t1时刻就开始消费那？
RabbitMQ 是功能强大的开源消息代理。根据官网称：也是使用量最广泛的消息队列。就像他的口号“Messaging that just works”，开箱即用使用简单，支持多种消息传输协议（AMQP、STOMP、MQTT）。
大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。
**Rabbitmq: 谁来创建 Queue 和 Exchange**
众所周知，消息队列的产品有好几种，这里我选择学习Kafka的原因，无他，公司在用。
---- 概述 RabbitMQ是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用之间共享数据或者将作业排队以便让分布式服务器进行处理。应用程序通过使用消息队列可以有效的进行解耦。 R
延迟队列就是进入该队列的消息会被延迟消费的队列。而一般的队列，消息一旦入队了之后就会被消费者马上消费。
一个生产者一个消费者 无需交换机，RabbitMQ会通过默认的交换机将消息投递到指定的队列，这是一种Direct类型的交换机，队列与它绑定时的binding key就是队列的名称
先看一下什么是同步调用。所谓的同步调用，就是说从请求的发起一直到最终的处理完成期间，请求的调用方一直在同步阻塞，等待调用的处理完成。下图所示的例子中，客户端代码 ClientCode，需要执行发送邮件 sendEmail 这样一个操作，它会调用 EmailService 进行发送，而 EmailService 会调用 SmtpEmailAdapter 类来进行处理，这个类会调用远程的一个服务，通过 SMTP 和 TCP 协议发送请求。
订阅关系一致指的是同一个消费者 Group ID 下所有 Consumer 实例所订阅的 Topic 、Tag 必须完全一致。
前几篇复习了下《线程的创建方式》、《线程的状态》、《Thread 的源码解析》、《wait、notify/notifyAll 源码解析》这几篇文章。这篇是第五篇生产者消费者模式在我们日常工作中用得非常多，比如：在模块解耦、消息队列、分布式场景中都很常见。这个模式里有三个角色，他们之间的关系是如下图这样的：
阻塞队列（BlockingQueue）是一个支持两个附加操作的队列。这两个附加的操作是：在队列为空时，获取元素的线程会等待队列变为非空。当队列满时，存储元素的线程会等待队列可用。阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。
Producer-Consumer与其说是模式，更不如说是一种思想，这种思想在很多模式中都有相应的体现，比如线程池，对象池，MQ等等。 Producer-Consumer的本质是在生产者与消费者之间引入一个通道（Channel暂且理解为一个队列）,该通道主要用于控制生产者与消费者的相对速率，尽可能的保证生产的Product尽快被消费，另一方面对二者进行解耦：生产者将生产的数据放入通道，消费者从相应的通道取出数据进行消费，生产者与消费者在各自的线程中，从而使双方的处理互相不影响。
之前我们已经实现了一个发送者将消息发送到队列，有多个消费者从队列里面拿数据，但是这样多个消费者是轮询的方式从队列里面拿数据的，每一个消费者拿到的数据都一样多，现在我们想要实现的是能者多劳，咋实现这个呢？
网关在收到APP秒杀请求后，直接给MQ发消息。 消息的内容，并不一定是APP请求的Request，只要包含足够字段：比如用户ID、设备ID、请求时间等。 还需包含这个请求ID和网关ID。
fanout exchange 可以做成备份的交换机，因为 fanout 的消息是广播的方式
ArrayBlockingQueue是一个基于数组的有界阻塞队列。它在创建时需要指定队列的大小，并且这个大小在之后是不能改变的。队列中的元素按照FIFO（先进先出）的原则进行排序。ArrayBlockingQueue是线程安全的，可以在多线程环境下安全地使用。
消息队列的基本作用是提供可靠、高效、异步的消息通信机制，实现系统之间的解耦、异步处理、削峰填谷、数据分发和错误处理等功能。它在分布式系统、微服务架构和大规模应用中发挥着重要的作用。
用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
Redis 怎么做消息队列？ - Kaito的回答 - 知乎 https://www.zhihu.com/question/20795043/answer/1931265868
也些人则反对，认为 Redis 会「丢」数据，最好还是用「专业」的队列中间件更稳妥。
RabbitMQ提供了6种消息模型，但是第6种其实是RPC，并不是MQ，因此我们只学习前五种方式，其中３、４、５这三种都属于订阅模型，只不过路由的方式不同。
在Java的并发编程领域，LinkedBlockingQueue是一个非常重要的类，它提供了一种高效且线程安全的方式来处理队列中的元素。该类位于java.util.concurrent包中，是BlockingQueue接口的一个实现，专门设计用于处理多线程环境中的生产者-消费者问题。在本篇博客中，我们将深入探讨LinkedBlockingQueue的内部工作原理、关键特性以及最佳实践。
其实借助RocketMQ-Dashboard就能高效的排查，里面有很多你想象不到的功能
RocketMQ 支持两种消息模式：集群消费（ Clustering ）和广播消费（ Broadcasting ）。
两个应用熊中需要远程传递数据，常规的做法是直接进行远程调用，使用 Http,或者 其他 RMI 方式进行调用，但是这种方式将系统耦合起来，一旦被调用的系统产生了故障或者升级，都可能会引起调用者导致不得不跟随升级。
生产者消费者模型 生产者消费者模式就是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。这个阻塞队列就是用来给生产者和消费者解耦的。
RabbitMQ是一个功能强大的开源消息队列系统，用于构建可靠的消息传递系统。消费者是RabbitMQ中的一个重要组件，负责从消息队列中获取并处理消息。
生产者发送的消息数量与消费者接收的消息数量不一致。例如生产者向rabbitmq投递了100条消息，消费者只从队列中接收到了80条消息，并且当前队列中已经没有任何消息。
嗨，大家好，我是小魔童哪吒，咱们从今天开始进入开源组件的学习，一边学习一边总结一边分享
首先基础数据的来源和怎么产生联系的？创建主题，有了主题，创建消费组，然后基于消费组这个大前提，执行订阅操作，订阅需要进行消费的主题信息，然后在订阅的基础上，进行队列的分配，而分配过程中，首先会去找到可分配的数据节点，然后根据条件进行匹配，然后进行返回。在这个过程中会执行元数据的变更和重平衡操作。特别的，这里需要重点关注队列是怎样产生和分配的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
