【技术栈】消息中间件MQ

1. 写在MQ之前

MQ出现之前，系统间交互的解决方案一般是 串行方式 或 并行方式

1.1 串行方式

串行方式没什么好说的，最符合人类思维逻辑

1.2 并行方式

并行方式：异步拆分，其实就是不影响主业务的运行，旁支业务进行异步处理。
思考：
1. 效率：异步处理确实提升了效率，吞吐量增大，最明显的就是处理时间缩短
2. 异步处理失败时如何处理？
2.1 异步失败重试（异步逻辑重试）
2.2 异步失败告知上一级调用者，有上一级调用者重新调用异步逻辑（上一级重试）
2.3 主动调用查询（上一级提供查询接口，用户点击该查询，可以调用一次异步逻辑；或者有异步调用逻辑提供查询接口，用户点击异步逻辑的查询）
2.4 人工补偿：出现问题时，在数据库进行记录，有运维系统查询，人工进行处理（一般重试几次失败后进入单独的一张表，提供运维系统查询）
总结：重试、主动查询、人工处理

1.3 系统间调用

MQ出现之前，系统间常用的消息传递方式：
方式1：Http接口调用
方式2：rpc调用
方式3：WebService服务接口调用
方式4：定时任务（上游系统记录数据至DB，每隔一定时间启动定时任务主动发送到下游系统，或者下游系统从DB中拉取数据，实时性不高）

MQ解决问题：
1. 上游系统高并发，下游系统处理能力有限（异常、超时、宕机）
2. 下游系统若出现故障，则导致业务失败（若是下单支付，则造成损失）
推荐课程：https://ke.qq.com/course/307932?taid=2162069357245148，课程讲解的挺不错的

2. 什么是MQ

MQ属于分布式系统中的一个子系统（消息子系统），主要负责消息（或数据）的发送、接收，利用其可靠有效的异步消息传递机制来集成其它子系统。

3. MQ的特点

MQ的特点：
1. 异步处理：一个长的同步流程，可以被拆解为短的异步流程（原则：异步流程可以延后操作，并不影响前面的交易）
2. 系统解耦：MQ前后的子系统进行解耦，松耦合可以使得前后子系统互不影响或减少影响，只要生产者成功把消息放入MQ中，消费者消费成功与否与生产者无关
3. 缓冲能力：MQ子系统也可以理解为一个缓存区（存储消息），消费者去该缓存区去消费（根据业务设置消费速率）
4. 高伸缩性：MQ子系统可以作集群，当然消费者也可以做集群处理，提升系统的稳定性和吞吐率
5. 高扩展性：和高伸缩性相比，扩展性指的是，MQ中的消息可以被多个业务系统消费，添加一个新的业务模块很容易，比如添加大数据日志分析、日志记录等功能模块

MQ与RPC的不同之处：
RPC远程过程调用，业务处理为同步处理；MQ子系统本身就是一个中间系统，自带缓存效应，可以异步解耦（解耦指的是MQ前后端子系统若使用RPC则存在强依赖，后端子系统若挂了，会影响整体交易流程）。

4. MQ的使用场景

主要应用：
1. 异步解耦：通过MQ，使得消息的生产者和消费者解耦，一个同步的处理流程可以被拆分为异步处理
2. 削峰填谷：生产者直接把消息发送到MQ中，消费者可以设置一个合适的速率进行消息消费
3. 日志处理：用于日志记录

5. 消息队列的两种模式

消息队列有两种模式：点对点、发布-订阅，主要区别就是发送到队列的消息是否能够重复消费。

5.1 点对点

消息队列中的消息被消费后，则不再保存，即不能重复消费（但可以有多个消费者，但对一个消息而言，只能被其中一个消费者消费）
若消息没有被消费，则一直被保存，一段时间过后，会产生相对意义上的脏数据（毕竟消费端就是来消费的）

5.2 发布-订阅

发布-订阅中存在一个Topic的概念，对于一个Topic中的消息，可以被多个消费者订阅消费，即可以重复消费。

5.3 JMS（Java Message Service）

JMS：Java消息服务，是JaveEE中面向MQ的API。
点对点与发布-订阅最初是由JMS定义的，ActiveMQ遵循了JMS规范，但是其它消息中间件并没有遵循。
推荐阅读：https://blog.csdn.net/lizhitao/article/details/47723105，整理的很不错，然后kafka和rabbit MQ有对比

面试中，遇到过和面试官驴唇不对马嘴的情况，每个人使用的消息中间件不同，实现方式是有区别的。
Kafka：
1. 只支持消息持久化（还有一种内存队列模式，消息队列保存在内存中）
2. 消息消费完后不会删除，故需要定时去清除（如一周清除一次）
3. 消费端为拉模型（还有一种推模型，相比拉模型更灵活），消费状态offset和订阅关系由客户端负责维护
4. 消息只存储一份，支持多订阅，可被多个消费组进行消费（但一个消费组中只能有一个消费者消费）
5. kafka是基于发布-订阅模型的，但是对一个消费组内而言，又可以认为是点对点的

6. 消费端消费方式

消费端消费方式有两种：
1. push推送模式：消息中间件维护消费端的相关信息（上线下线那些机器，数据是否被消费者成功消费，需要消费者告知执行结果），压力较大；另，若生产的生产消息过多，会直接给消费后端带来压力（除非加消费端机器，不然很容易导致错误或宕机）
2. pull拉取模式：消息消费的相关信息有消费客户端维护，减少消息中间件的压力，也更加灵活

通过推拉模式也衍生出了各种组合，如先推后拉、先拉后推，没过多研究，感兴趣请度娘

【说明】梳理知识用，有些地方未做验证，请保持怀疑态度。