最近刷題，看到了有問中間件的題目，于是整理了一些中間件的知識，大多是在小破站上的筆記，僅供大家參考~

主要分為七個部分來分享：

一、常見的中間件

二、什么是隊列？

三、常見消息隊列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）消息，通知隊列可以刪除已處理的消息。