《架构实践--软件架构设计的过程》读书笔记

MQ消息队列
references:

详解消息队列的常见功能场景与使用精髓

消息队列常见问题和解决方案

小白入门微服务(2) - 消息队列初体验

什么是MQ
消息队列（MQ）是一种不同应用程序之间（跨进程）的通信方法。

应用程序通过写入和检索出入列队的数据（消息）来通信，而无需通过专用连接来链接它们。

消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用（Remote Procedure Call. RPC）的技术。

排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求，这样就天然地实现了异步的目标

为什么要用MQ？
异步处理 - 增加吞吐量；

削峰填谷 - 提高系统稳定性；

系统解耦 - 业务边界隔离；

数据同步 - 最终一致性保证。

MQ的优缺点
异步、解耦、消峰填谷这是消息队列最大的优点，除了这些消息队列还可以会解决一些我们特殊业务场景的问题。但是缺点主要在于系统的可用性、复杂性、一致性问题，引入消息队列后，需要考虑MQ的可用性，万一MQ崩溃了岂不是要爆炸？而且复杂性明显提高了，需要考虑一些消息队列的常见问题和解决方案，还有就是一致性问题，一条消息由多个消费者消费，万一有一个消费者消费失败了，就会导致数据不一致。

有哪几种
从处理业务的范围来看
应用内部 - 采用线程池，比如 Java ThreadPool 中 BlockingQueue 来做任务级别的缓冲与处理；

应用外部 - 比如 RabbitMQ、ActiveMQ 就是做应用级别的队列，方便进行业务边界隔离与提高吞吐量。

从技术上来看有两种模型

Pull 模型：消费者主动请求消息队列，获取队列中的消息；

Push 模型：消息队列主动推送消息到消费者。

其中 Pull 模式可以控制消费速度，不必担心自己处理不了消息，只需要维护队列中偏移量 Offset。所以对于消费量有限并且推送到队列的生产者不均匀的情况下，采用 Pull 模式比较合适。

Push 比较适合实时性要求比较高的情况，只要生产者消息发送到消息队列中，队列就会主动 Push 消息到消费者。不过这种模式对消费者的能力要求就提高很多，如果出现队列给消费者推送一些不能处理的消息，消费者出现 Exception 情况下，就会再次入队列，造成消费堵塞的情况。

不过互联网业界比较成熟的队列主要以采用 Pull 模式为主，像 Kafka、RabbitMQ（两种方式都支持）、RocketMQ 等。