MQ(消息队列)在软件架构中是经常被使用的，特别是在分布式系统中也是使用频率很高的组件。
在分布式环境下，系统间的相互依赖，最终会会导致整个依赖关系混乱，特别在微服务环境下，会出现相互依赖，甚至是循环依赖的情况，对后期系统的拆分和优化都带来极大负担。那么我们就可以用MQ来做处理。上游系统将数据投递到MQ，下游系统取MQ的数据来进行消费，投递和消费可以用同步的方式处理，因为MQ接收数据的性能是非常高的，不会影响上游系统的性能。
如果采用同步的方式，系统的性能(并发量，吞吐量，响应时间)会有瓶颈。怎么样才能解决这个问题呢?引入消息队列，将不必要的业务逻辑异步处理。
异步处理也可以引来 并行处理的使用姿势。在工作中，我们基于消息开发了一个简单的分布式任务处理组件。该组件简单分为三块分别是 切分、加载、执行三个阶段
每个阶段都是以作为消费者，然后处理完毕后再作为生产者发送消息。消息消费无状态，可以按需无限拓容。
由于使用消息，我们的链路变成了生产者发送消息，消息中间件存储消息，最后消费者从消息中间件拉取消息的一个过程。而消息中间件的存储能力可以有明显效果地的帮助消费者进行缓冲。试想下，正常流量下花钱的人可以愉快的进行消费，瞬时高峰流量来的时候，消费者消费能力跟不上，刚好阻塞在消息中间件，等峰值过后，消费者又能很快的将阻塞的消息进行消费。
大部分开源的MQ中间件基本都支持一对多或者广播的模式，而且都能够准确的通过规则选择分发的对象。这样上游的一份数据，众多下游系统中，能够准确的通过规则选择是否接收这一些数据，这样扩展性就很强了。
以上四种是MQ中间件最常见的场景，但是我们细想，MQ中间件的引入会带来什么样的问题呢?那就是实时性。所以MQ中间件使用的先决条件是：能容忍延迟，只要求最终一致性较为合适。
不能先进先出，都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。而且，最重要的是，数据是只有一条数据在使用中。 这也是MQ在诸多场景被使用的原因。
发布订阅是一种很高效的解决方法，如果不发生阻塞，基本能当做是同步操作。这种解决方法能很有效的提升服务器利用率，这样的应用场景非常广泛。
持久化确保MQ的使用不只是一个部分场景的辅助工具，而是让MQ能像数据库一样存储核心的数据。
在现在大流量、大数据的使用场景下，只支持单体应用的服务器软件基本是没办法使用的，支持分布式的部署，才能被普遍的使用。而且，MQ的定位就是一个高性能的中间件。
点对点，一个发，一个消费。涉及到的角色 发布者(Publisher)、消费者(Consumer)、消息队列(Queue)
消费者消费完成消息，需要向队列Ack，消息队列发现消息消费成功即做消息移除
发布订阅模式，一个发布，多方订阅。涉及到的角色有 发布者(Publisher)、主题(Topic)、订阅者(Subscriber)。
第二种只能紧急修复问题，发布上线，在阻塞的过程中会造成大量的消息积压，这样的一种情况也可优先考虑临时扩容
重复消费一般发生下消费端，比如消费者处理完毕，在准备进行ack的时候出现了问题，应用重启后，消息中间件以为该消息还未处理又推给了消费者，或者消费者拉取的时候重复。
消息中间的丢失：一般中间件可设为丢弃策略，大部分MQ中间件产品能保证数据不丢失，这样的一种情况基本不用考虑。
消费丢失：有的消息中间件支持自动ack，当消费者消费到消息，消息中间件也不管是否消费成功自动ack。这时候一般选择消费者主动ack比较合适。
消息顺序性一般是通过MQ中间件保证，大部分MQ中间件只能做到局部有序，比如Kafka，只能保证单个partition队列有序。有些也会做到全局有序，但是成本比较高。笔者目前服务的公司现在是支持全局有序的。