深夜更新 一文读懂MQ消息队列.docxVIP

深夜更新 - 一文读懂MQ消息队列 原创 2021-02-21 —?扫描二维码?—加入架构集结群 ?? 对技术感爱好的同学可进群（备注:Java） MQ（消息队列）在软件架构中是经常被使用的，特殊是在分布式系统中也是使用频率很高的组件。 以下从消息队列的使用场景、概念、常见问题及处理方案来具体讲解。 一、消息队列使用场景 1.1 常见的使用场景 系统解耦 在分布式环境下，系统间的相互依靠，最终会会导致整个依靠关系混乱，特殊在微服务环境下，会消灭相互依靠，甚至是循环依靠的情况，对后期系统的拆分和优化都带来极大负担。那么我们就可以用MQ来进行处理。上游系统将数据投递到MQ，下游系统取MQ的数据进行消费，投递和消费可以用同步的方式处理，由于MQ接收数据的功能是格外高的，不会影响上游系统的功能。 异步处理 假如接受同步的方式，系统的功能（并发量，吞吐量，响应时间）会有瓶颈。如何处理这个问题呢？引入消息队列，将不必要的业务规律异步处理。 异步处理也可以引来?并行处理的使用姿态。在工作中，我们基于消息开发了一个简约的分布式任务处理组件。该组件简约分为三块分别是 切分、加载、执行三个阶段 每个阶段都是以作为消费者，然后处理完毕后再作为生产者发送消息。消息消费无形态，可以按需无限拓容。 流量削峰 由于使用消息，我们的链路变成了生产者发送消息，消息两头件存储消息，最终消费者从消息两头件拉取消息的一个过程。而消息两头件的存储力量能够有效的挂念消费者进行缓冲。试想下，正常流量下消费者能够开心的进行消费，瞬时高峰流量来的时候，消费者消费力量跟不上，刚好堵塞在消息两头件，等峰值过后，消费者又能很快的将堵塞的消息进行消费。 流量削锋也是消息队列中的常用场景，一般在秒宰或团抢活动中使用广泛！ 数据分发 大部分开源的MQ两头件基本都支持一对多或者广播的模式，而且都可以依据规章选择分发的对象。这样上游的一份数据，众多下游系统中，可以依据规章选择能否接收这些数据，这样扩展性就很强了。 1.2 消息使用的先决条件 以上四种是MQ两头件最常见的场景，但是我们细想，MQ两头件的引入会带来什么问题呢？那就是实时性。所以MQ两头件使用的先决条件是：能容忍延迟，只需求最终全都性较为合适。 二、消息相关的概念 MQ特点 先进先出不能先进先出，都不能说是队列了。消息队列的挨次在入队的时候就基本已经确定了，一般是不需人工干涉的。而且，最重要的是，数据是只要一条数据在使用中。?这也是MQ在诸多场景被使用的缘由。 发布订阅发布订阅是一种很高效的处理方式，假如不发生堵塞，基本可以当做是同步操作。这种处理方式能格外有效的提升服务器利用率，这样的应用场景格外广泛。 长久化长久化确保MQ的使用不只是一个部分场景的协助工具，而是让MQ能像数据库一样存储核心的数据。 分布式在现在大流量、大数据的使用场景下，只支持单体应用的服务器软件基本是无法使用的，支持分布式的部署，才能被广泛使用。而且，MQ的定位就是一个高功能的两头件。 在JMS标准中，有两种消息模型P2P（Point toPoint）和Publish/Sub(Pub/Sub)。 P2P 点对点，一个发，一个消费。涉及到的角色 发布者（Publisher）、消费者（Consumer）、消息队列（Queue） 特点 一个消息只能被一个消费者消费，消费后会从队列里移除 发布者和消费者无关系，发布者发送消息的行为不会随消费者而转变 消费者消费完成消息，需要向队列Ack，消息队列发觉消息消费成功即做消息移除 Pub/Sub 发布订阅模式，一个发布，多方订阅。涉及到的角色有 发布者（Publisher）、主题（Topic）、订阅者（Subscriber）。 特点 每个消息可以有多个消费者 针对某个主题（Topic）的订阅者，必需创建一个订阅者之后，才能消费发布者的消息 为了消费消息，订阅者必需保持运转的形态 三、常见问题及处理方案 消息堵塞 1、消息堵塞一般都是流量激增，超过消费者消费力量； 2、或者消费者消灭规律问题，导致不断的重试或长时间等待。 第一种可以通过扩容处理 其次种只能紧急修复问题，发布上线，在堵塞的过程中会形成大量的消息积压，这种情况也可以考虑临时扩容 反复消费 反复消费一般发生下消费端，比如消费者处理完毕，在预备进行ack的时候消灭了问题，应用重启后，消息两头件以为该消息还未处理又推给了消费者，或者消费者拉取的时候反复。 一般的做法是消费端做幂等。 消息丢失 消息丢失一般分为生产者发送失败、消息两头件丢失、消费丢失。 生产者丢失：可能以为网络问题或者消息两头处理失败导致，消息遗漏。 消息两头的丢失：一般两头件可以设置丢弃策略，大部分MQ两头件产品可以保证数据不丢失，这种情况基本不用考虑。 消费丢失：有的消息两头