凡网站建设/长尾关键词网站

最近刷题，看到了有问中间件的题目，于是整理了一些中间件的知识，大多是在小破站上的笔记，仅供大家参考~

主要分为七个部分来分享：

一、常见的中间件

二、什么是队列？

三、常见消息队列MQ的比较

四、队列的优点和缺点

五、消息队列的原理

六、为什么使用消息队列？

七、队列的测试点

八、高频软件测试面试题

一、常见的中间件

Redis：缓存中间价

MQ：消息队列中间件

Nginx：Web服务器中间件

二、什么是队列？

队列（Queue）是一种常见的数据结构，用于按照先进先出（FIFO，First In First Out）的原则管理元素。这意味着最先被添加到队列的元素将首先被移除。队列的操作通常包括两个主要动作：入队（Enqueue）和出队（Dequeue） 。

三、常见消息队列MQ的比较

ActiveMQ：比较老，一般不用了

RabbitMQ：大部分公司够用了，除非像阿里并发那么大的公司

RocketMQ：阿里在用的

Kafka：主要用于记录日志，例如淘宝的足迹功能

四、队列的优点和缺点

1、优点

解耦

异步

流量削峰填谷

2、缺点

可用性低

复杂度

一致性问题（例如消息丢失，消息重复等等，导致两个系统数据不一致）

五、消息队列的原理

下面以用户下单这个场景为例，分享下整个过程：

一）生产者如何将消息可靠投递到消息队列（MQ）：

1. 客户端发送消息到消息队列MQ。
2. 消息队列MQ将消息进行持久化，并向客户端发送 Ack 消息。由于网络问题可能导致 Ack 消息无法及时发送至客户端，因此客户端在等待一段超时时间后，会重新传送消息。
3. 客户端在收到 Ack 消息后，确认消息已被成功投递。

二） 消息队列如何将消息可靠投递给消费者：

1. 消息队列MQ将消息推送给客户端（或者客户端通过拉取方式获取消息）。
2. 客户端接收并完成业务逻辑处理。
3. 客户端向消息队列MQ发送 Ack 消息，通知消息队列删除该消息。由于网络问题可能导致 Ack 失败，客户端会收到重复的消息，从而引发了消费幂等性的问题。
4. 消息队列删除已被成功消费的消息。

六、为什么使用消息队列？

主要用于解耦、异步、流量削峰填谷。

1、解耦

如果不加中间件MQ，订单系统直接调用库存系统，当库存系统出现故障时，用户就会下单失败。加了中间件之后，就不会出现下单失败了，用户下单之后，把订单id传给MQ，监控系统发现库存系统挂了之后，立马修复，最后还是可以下单成功。

2、异步

如果不加中间件MQ，下单的时候，订单系统会同步调用库存系统，有了MQ之后，下单后，订单系统只要把订单id传给MQ即可。

3、流量削峰填谷

例如B是订单系统，C是库存系统，C系统每分钟只能承受1W的并发，现在突然有30W的并发，那先把订单消息发送给MQ，C系统从MQ拉取信息，处理速度还是每分钟1W，最后花费30分钟来处理，用时间换空间。

七、队列的测试点

一）正向的业务逻辑测试

1、数据正确性

产者推送消息，消费者能正常消费信息，比如消息发送的字段以及接收的字段有无缺失，且保持一致

2、时序

不同时序推送消息，先后顺序是否与预期一致。

注意队列优先级，可使用事务解决

二）反向的异常测试

1、消息推送失败是否有重试

如因为网络原因导致的消息丢失，是否有补发和重试机制（用定时任务跑），通常情况下Produce会设置补发。

2、避免重复消息

例如生产者重复推送同一条数据，由于RocketMQ天生就有消息重复发送的机制，所以当产生消息重新发送时，如何对此问题进行处理？通常情况下要对消费端的服务做幂等处理，数据库里添加唯一索引，保证消息不被重复消费。

三）性能测试（消费积压）

主要就是通过性能测试，看看在高并发访问的情况下，系统正确处理消息的能力，是否会出现消息队列拥堵，宕机等情况。

解决消费积压的办法：

1. 首先要快速解决消息积压问题，比如加大consumer消费数量，消费频次；
2. 临时紧急扩容，比如临时征用10倍的机器来部署consumer程序，这个程序部署上去消费积压的数据，等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息。

八、高频软件测试面试题

1、如何保证消息不丢失？

消息队列将收到的消息持久化到磁盘中，以保证消息队列异常或重启的情况下，消息不会丢失

2、消息队列的工作原理是什么？

生产者创建消息并将其发送到消息队列， 消费者从消息队列中接收消息，并异步地处理这些消息， 消费者在成功处理消息后向消息队列发送确认（Acknowledge）消息，通知队列可以删除已处理的消息。