使用RabbitMQ優(yōu)化用戶登錄功能

1. 前言

Hello，大家好。通過上述幾個(gè)小節(jié)的介紹，我們已經(jīng)對(duì) RabbitMQ 中的消息發(fā)送模式有了代碼實(shí)現(xiàn)層面的了解，這些實(shí)操代碼是應(yīng)用 RabbitMQ 基礎(chǔ)中的基礎(chǔ)，同學(xué)們必須要掌握并記憶。

那么，從本節(jié)開始，會(huì)為大家?guī)恚谖覀兊膶?shí)際的一個(gè)日常開發(fā)工作中，針對(duì)常用的幾個(gè)功能，我們應(yīng)該如何使用 RabbitMQ 來進(jìn)行實(shí)現(xiàn)，同時(shí)，通過對(duì)常用功能的 RabbitMQ 集成，可以提升傳統(tǒng)功能實(shí)現(xiàn)中的一些性能等指標(biāo)，這對(duì)后續(xù)傳統(tǒng)功能的優(yōu)化是很有必要的。

本小節(jié)會(huì)為同學(xué)們介紹，如何使用 RabbitMQ 消息中間件，去優(yōu)化我們使用傳統(tǒng)的方式，來實(shí)現(xiàn)的用戶登錄功能點(diǎn)，包括對(duì)傳統(tǒng)用戶登錄功能的概述，以及使用 RabbitMQ 進(jìn)行優(yōu)化的關(guān)鍵步驟，希望同學(xué)們可以對(duì)本節(jié)內(nèi)容有所了解。

本節(jié)主要內(nèi)容：

• 傳統(tǒng)用戶登錄功能概述；

• 使用 RabbitMQ 優(yōu)化傳統(tǒng)用戶登錄功能。

2.傳統(tǒng)用戶登錄功能概述

2.1 傳統(tǒng)實(shí)現(xiàn)方案介紹

眾所周知，我們現(xiàn)在的信息化系統(tǒng)項(xiàng)目，項(xiàng)目的首要功能模塊，基本上都會(huì)要求我們來設(shè)計(jì)并實(shí)現(xiàn)一個(gè)完備的用戶模塊，而這個(gè)用戶模塊中，必定會(huì)包含用戶注冊(cè)與用戶登錄功能點(diǎn)。

只有在項(xiàng)目中實(shí)現(xiàn)了用戶注冊(cè)與用戶登錄這兩個(gè)最基本的功能點(diǎn)，我們的項(xiàng)目功能才能繼續(xù)向后進(jìn)行開發(fā)，因?yàn)轫?xiàng)目后續(xù)的功能，或多或少都會(huì)與這兩個(gè)功能點(diǎn)相聯(lián)系。

所以，這就要求我們?cè)趯?shí)現(xiàn)用戶注冊(cè)與用戶登錄功能時(shí)，要從多方面進(jìn)行考慮， 如果有一點(diǎn)我們沒有考慮到，很可能在進(jìn)行項(xiàng)目后續(xù)功能開發(fā)時(shí)，還要回過頭去，修改這兩個(gè)基本功能，從而與項(xiàng)目后續(xù)的功能相結(jié)合。

那么，傳統(tǒng)的用戶登錄功能的實(shí)現(xiàn)方案是什么樣的呢？

傳統(tǒng)用戶登錄功能流程介紹

我們首先接觸用戶登錄功能或者用戶注冊(cè)功能，有絕大部分同學(xué)是在自己的學(xué)校內(nèi)，也就是學(xué)校老師教授我們的內(nèi)容，往往這種實(shí)現(xiàn)方式都會(huì)存在諸多問題，下面讓我們來看一下這種方式是如何實(shí)現(xiàn)的。

針對(duì)用戶登錄功能，對(duì)于后端開發(fā)的同學(xué)，我們首先需要接收前端傳遞過來的數(shù)據(jù)，也就是用戶的登錄數(shù)據(jù)，然后我們會(huì)根據(jù)這一用戶登錄數(shù)據(jù)來進(jìn)行相應(yīng)的邏輯檢驗(yàn)。

這些邏輯校驗(yàn)包括對(duì)用戶的名稱進(jìn)行檢測(cè)，以查驗(yàn)當(dāng)前要登錄的用戶是否在我們的系統(tǒng)中存在，如果不存在，則提示用戶不存在與本系統(tǒng)中，如果存在，則檢測(cè)用戶所輸入的登錄密碼是否與用戶注冊(cè)時(shí)所填寫的一致，如果不一致，則提示用戶，用戶登錄密碼錯(cuò)誤。

如果當(dāng)前要登錄的用戶在本系統(tǒng)中存在，且用戶所輸入的登錄密碼與用戶注冊(cè)時(shí)所填寫的登錄密碼一致，則表明用戶登錄成功，此時(shí)，需要提示用戶登錄成功，并跳轉(zhuǎn)到我們的系統(tǒng)首頁。下面，我們來通過一個(gè)功能流程圖來體現(xiàn)上述的業(yè)務(wù)流轉(zhuǎn)過程：

通過上述功能流程圖，我們可以很清楚地理解上述傳統(tǒng)用戶登錄功能的實(shí)現(xiàn)過程，如果沒有理解的同學(xué)，建議多看幾次，理解這一流程之后我們?cè)倮^續(xù)學(xué)習(xí)下面的內(nèi)容。

傳統(tǒng)用戶登錄功能代碼實(shí)現(xiàn)

以 SpringBoot 框架為例，我們來實(shí)現(xiàn)一下上述的用戶登錄功能，實(shí)現(xiàn)代碼如下所示：

實(shí)現(xiàn)代碼：

public Response<User> userLogin(User user, HttpSession session){
    int userExistsCount = userMapper.selectUserExixtsByUsername(user.getUsername());
    if (userExistsCount <= 0){
        return Response.createByError("用戶不存在");
    }
    User userLogin = userMapper.selectLoginUserByUsernamePassword(user.getUsername(), user.getPassword());
    if (userLogin != null){
        userLogin.setPassword("");
        session.setAttribute("loginUser", userLogin);
        return Response.createBySuccess("登錄成功", userLogin);
    }
    return Response.createByError("用戶登錄密碼輸入錯(cuò)誤，請(qǐng)重新輸入");
}

代碼解釋：

第 1 行，我們定義了一個(gè)名為 userLogin 的方法來處理用戶登錄的業(yè)務(wù)邏輯，該方法的返回值是 Response 類型，并且泛型被指定為 User 類型，這表明，我們的方法最終會(huì)返回 User 用戶數(shù)據(jù)。

在該方法中，我們定義了兩個(gè)參數(shù)，分別是 User 類型的 user 參數(shù)，以及 HttpSession 類型的 session 參數(shù)。其中，user 參數(shù)就表示用戶登錄時(shí)所填入的登錄數(shù)據(jù)，session 參數(shù)則表示存儲(chǔ)用戶登錄狀態(tài)和登錄數(shù)據(jù)的參數(shù)。

第 2-5 行，我們通過獲取到用戶的用戶名，并且調(diào)用數(shù)據(jù)庫(kù) ORM 層的方法，來對(duì)系統(tǒng)數(shù)據(jù)庫(kù)進(jìn)行查詢，查詢當(dāng)前用戶名是否存在我們的數(shù)據(jù)庫(kù)中，如果存在，則表明用戶注冊(cè)過我們的系統(tǒng)，即這個(gè)用戶是在我們的系統(tǒng)中的。如果不存在，則會(huì)提示用戶當(dāng)前用戶名不存在。

第 6-14 行，我們通過獲取到的用戶的用戶名和用戶登錄密碼，調(diào)用數(shù)據(jù)庫(kù) ORM 層的犯法，來對(duì)系統(tǒng)數(shù)據(jù)庫(kù)進(jìn)行查詢，查詢當(dāng)前用戶名和密碼是否在系統(tǒng)中匹配。

即，只有用戶名匹配的話是不行的，還要將這個(gè)用戶名和其所對(duì)應(yīng)的密碼進(jìn)行匹配，當(dāng)使用這兩個(gè)條件進(jìn)行匹配查詢，且可以正確查詢到結(jié)果時(shí)，表明用戶已經(jīng)登錄成功了，此時(shí)，我們可以將用戶登錄的數(shù)據(jù)放到 session 中，以備后續(xù)功能的使用，與此同時(shí)，我們還應(yīng)該提示用戶登錄成功了。

如果根據(jù)這兩個(gè)查詢條件，沒有查詢到任何數(shù)據(jù)，即 userLogin 變量為 null 時(shí)，則表明當(dāng)前用戶名是存在的，但是當(dāng)前登錄用戶輸入的登錄密碼和注冊(cè)時(shí)所輸入的是不一樣的，此時(shí)，系統(tǒng)會(huì)提示用戶，用戶登錄密碼錯(cuò)誤，可以進(jìn)行重試。

Tips:
1. 在我們的 userLogin 方法中存在一個(gè)參數(shù) session ，我們只是對(duì) session 進(jìn)行了簡(jiǎn)單介紹，因?yàn)檫@不屬于我們的重點(diǎn)內(nèi)容，所以，有不了解的同學(xué)可以自行查閱資料來了解；
2. 可以看到，在 userLogin 方法中，存在一行 userLogin.setPassword("") ，這句代碼的作用是將用戶登錄成功后的密碼設(shè)置為空，并不會(huì)同步更新數(shù)據(jù)庫(kù)，并將 userLogin 用戶數(shù)據(jù)返回給前端，出于安全考慮，這里將密碼設(shè)置為空了，前端是獲取不到用戶的登錄密碼的；
3. userLogin 方法中所使用的 userMapper 為 MyBatis 數(shù)據(jù)庫(kù) ORM 框架所定義的內(nèi)容，有不了解的同學(xué)可以自行查閱資料進(jìn)行了解，本小節(jié)不會(huì)對(duì)其進(jìn)行介紹。

通過上述代碼的編寫，我們基本上實(shí)現(xiàn)了傳統(tǒng)的用戶登錄功能，但是這種登錄功能是最簡(jiǎn)單的實(shí)現(xiàn)，完全沒有考慮其他因素，如果我們?cè)趯?shí)際項(xiàng)目中這樣來實(shí)現(xiàn)，那么在開發(fā)后續(xù)功能時(shí)，必定會(huì)出現(xiàn)一些意料之中的問題。

那么，我們采用這種實(shí)現(xiàn)方式所實(shí)現(xiàn)的用戶登錄功能到底有哪些弊端呢？下面就讓我們一探究竟。

2.2 傳統(tǒng)實(shí)現(xiàn)方案中存在的弊端

整體來說，我們傳統(tǒng)的實(shí)現(xiàn)用戶登錄功能的業(yè)務(wù)邏輯還是正確的， 不管我們?cè)僭趺磳?duì)用戶登錄功能進(jìn)行優(yōu)化，這個(gè)傳統(tǒng)的用戶登錄功能業(yè)務(wù)流程始終不會(huì)發(fā)生改變，發(fā)生改變的只是我們的代碼實(shí)現(xiàn)層。

那么，傳統(tǒng)實(shí)現(xiàn)方案中存在的弊端，也就存在于我們的功能代碼實(shí)現(xiàn)層上。

弊端一 用戶登錄狀態(tài)的處理

對(duì)于上述代碼來說，我們處理用戶登錄狀態(tài)所采用的手段，是通過將用戶登錄成功后的數(shù)據(jù)存放在服務(wù)端中的 session 中，后續(xù)如果需要使用到用戶登錄狀態(tài)，我們可以直接對(duì) session 進(jìn)行判斷，并返回相應(yīng)的判斷結(jié)果。

但是，這種模式如果遇到了前后端分離的項(xiàng)目，我們就無法再使用 session 了，因?yàn)榍岸丝蚣懿荒苤苯硬倏匚覀兒蠖说?session ，所以，我們就要把 session 替換掉，替換成前后端均可操控的手段來實(shí)現(xiàn)。

弊端二 高并發(fā)環(huán)境下容易出現(xiàn)的問題

如果我們的項(xiàng)目在使用過程中出現(xiàn)了用戶激增的情況，即會(huì)有越來越多的人來訪問我們的用戶登錄功能，如果我們只是采用上述的實(shí)現(xiàn)方式來處理，不會(huì)這種情況進(jìn)行考慮，那么我們的用戶登錄功能就會(huì)在非常短的一段時(shí)間過后癱瘓，我們的用戶登錄功能不會(huì)再返回任何響應(yīng)數(shù)據(jù)。

這就是高并發(fā)環(huán)境下傳統(tǒng)的用戶登錄功能最容易出現(xiàn)問題的地方，而這一地方則體現(xiàn)在用戶登錄前和用登錄后的數(shù)據(jù)不一致問題上。

即，在高并發(fā)環(huán)境下，我們的用戶 A 進(jìn)行了登錄，與此同時(shí)，我們的用戶 B 也進(jìn)行了登錄，這兩個(gè)用戶進(jìn)行登錄的時(shí)刻恰好重疊了，由于我們并沒有對(duì)這種場(chǎng)景進(jìn)行處理，所以，在這兩個(gè)用戶登錄之后，就有可能出現(xiàn)返回給用戶 A 的用戶數(shù)據(jù)，其實(shí)是用戶 B 的。

除了數(shù)據(jù)不一致問題，還有一種問題也比較容易出現(xiàn)，那就是當(dāng)我們的用戶數(shù)激增時(shí)，同一時(shí)刻進(jìn)行登錄的用戶也隨之激增，我們的用戶登錄功能接口無法在一瞬間響應(yīng)這么多的用戶登錄請(qǐng)求，導(dǎo)致了后續(xù)登錄的用戶只能等待，只能等待當(dāng)先用戶登錄完成之后，才能進(jìn)行登錄。

這個(gè)等待過程是不確定的，可能很長(zhǎng)，也可能很短，這就對(duì)用戶的體驗(yàn)造成了非常嚴(yán)重的不良影響。

上述就是兩個(gè)在傳統(tǒng)用戶登錄功能中，出現(xiàn)的顯而易見的問題，我們會(huì)對(duì)這兩個(gè)功能進(jìn)行優(yōu)化，并且會(huì)使用 RabbitMQ 對(duì)第二個(gè)弊端進(jìn)行優(yōu)化。

3 使用 RabbitMQ 優(yōu)化傳統(tǒng)用戶登錄功能

3.1 優(yōu)化用戶登錄狀態(tài)的處理問題

前面我們已經(jīng)介紹了，在傳統(tǒng)用戶登錄功能中，當(dāng)我們的項(xiàng)目架構(gòu)采用前后端分離的架構(gòu)方式來管理時(shí)，出現(xiàn)的用戶登錄狀態(tài)的問題，那么我們可以怎樣來優(yōu)化這個(gè)問題呢？

優(yōu)化出現(xiàn)的用戶登錄狀態(tài)問題，不需要我們使用 RabbitMQ 來處理，我們可以將 session 參數(shù)使用一種 token 機(jī)制來替代掉。

即在處理用戶狀態(tài)時(shí)，我們不使用 session 來存儲(chǔ)，而是使用 token 來進(jìn)行存儲(chǔ)，這個(gè) token 我們一般會(huì)使用 JWT 框架來生成，并為生成的 token 設(shè)置一個(gè)有效期。

這樣一來，當(dāng)前端發(fā)來用戶登錄請(qǐng)求時(shí)，就會(huì)將用戶登錄成功的 token 進(jìn)行傳遞，然后我們后臺(tái)需要接收這個(gè) token ，并將這個(gè)加密的 token 進(jìn)行解析。這樣一來，前端在用戶登錄成功之后，會(huì)將這個(gè) token 保存到前端的狀態(tài)機(jī)中，而后端默認(rèn)是會(huì)存儲(chǔ)這個(gè) token 的。

這就實(shí)現(xiàn)了一種前后端都可以操作這個(gè) token 的功能，通過這樣的優(yōu)化，無論是前后端分離項(xiàng)目，還是其他類型的一些項(xiàng)目，我們都可以很好地處理用戶的登錄狀態(tài)和用戶數(shù)據(jù)。

3.2 優(yōu)化高并發(fā)環(huán)境下的用戶登錄功能

在高并發(fā)環(huán)境下，我們的用戶登錄功能需要在同一時(shí)刻，處理大量的用戶請(qǐng)求，如果我們的用戶登錄功能沒有考慮到這樣的業(yè)務(wù)場(chǎng)景，也就不會(huì)對(duì)這種業(yè)務(wù)場(chǎng)景進(jìn)行優(yōu)化，所以，一旦請(qǐng)求量上來之后，我們的用戶登錄功能肯定就會(huì)癱瘓，不能正常使用了。

我們可以從兩個(gè)角度去優(yōu)化高并發(fā)環(huán)境下的用戶登錄功能。第一個(gè)角度就是優(yōu)化我們的數(shù)據(jù)庫(kù)訪問頻率。

角度一：優(yōu)化數(shù)據(jù)庫(kù)訪問頻率

我們都知道，在后臺(tái)程序代碼中，比較耗時(shí)的操作無疑就是訪問數(shù)據(jù)庫(kù)了，因?yàn)樵L問數(shù)據(jù)庫(kù)之前，我們需要先通過代碼的方式，來將我們的項(xiàng)目與數(shù)據(jù)庫(kù)相連接，最后，通過 ORM 框架來達(dá)到對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)增刪改查的一個(gè)目的。

我們?cè)趯?duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行增刪改查時(shí)，需要我們將處理好的數(shù)據(jù)傳入到數(shù)據(jù)庫(kù)中，然后數(shù)據(jù)庫(kù)通過執(zhí)行 SQL 腳本來根據(jù)我們的數(shù)據(jù)去處理數(shù)據(jù)庫(kù)中的數(shù)據(jù)，并最后返回給我們處理數(shù)據(jù)的結(jié)果。

在用戶登錄功能中，訪問數(shù)據(jù)庫(kù)的次數(shù)一般都是兩次，第一次是校驗(yàn)當(dāng)前要登錄的用戶名在系統(tǒng)中是否存在；第二次是校驗(yàn)當(dāng)前要登錄的用戶名和密碼是否在系統(tǒng)中匹配。 只有這兩個(gè)校驗(yàn)通過之后，用戶才能成功登錄，而數(shù)據(jù)庫(kù)的耗時(shí)操作也就出現(xiàn)在這兩個(gè)過程中。

那么我們應(yīng)該怎么來優(yōu)化呢？

我們可以使用 Redis 來緩存我們的用戶請(qǐng)求數(shù)據(jù)，即當(dāng)有用戶請(qǐng)求數(shù)據(jù)請(qǐng)求我們的用戶登錄功能接口時(shí)，我們會(huì)首先進(jìn)行第一次的數(shù)據(jù)庫(kù)操作，此時(shí)，在數(shù)據(jù)庫(kù)將操作結(jié)果返回給我們時(shí)，我們可以將這一結(jié)果緩存在 redis 中，后續(xù)如果再有相同的請(qǐng)求時(shí)，我們可以直接訪問 redis ，而不是再次重復(fù)地去訪問我們的數(shù)據(jù)庫(kù)。

這樣可以提高我們的服務(wù)響應(yīng)速度，因?yàn)樵L問 redis 的速度要比單純?cè)L問數(shù)據(jù)庫(kù)的速度快很多。所以，第二次的數(shù)據(jù)庫(kù)操作我們也可以這樣來進(jìn)行處理。

Tips: 關(guān)于什么是 Redis ，以及 redis 的一些基本操作，我們會(huì)在后續(xù)的小節(jié)中進(jìn)行介紹，這里只介紹功能優(yōu)化的思路，感興趣的同學(xué)可以自行查閱資料實(shí)現(xiàn)。

這是第一種優(yōu)化思路，接下來讓我們看第二種優(yōu)化思路，即優(yōu)化我們的用戶請(qǐng)求序列。

角度二：優(yōu)化用戶請(qǐng)求序列

此種優(yōu)化措施，就需要使用我們的 RabbitMQ 了。

我們都知道，高并發(fā)環(huán)境下的請(qǐng)求數(shù)量是非常多的，那么，對(duì)于一個(gè)用戶登錄功能接口而言，在高并發(fā)環(huán)境下接收的用戶請(qǐng)求也是非常多的，而且這些用戶請(qǐng)求都是無序的。

即，例如我們?cè)谝凰查g有 5000 個(gè)用戶登錄請(qǐng)求，根據(jù)計(jì)算機(jī) CPU 以及操作系統(tǒng)的處理時(shí)序可以得出，在這 5000 個(gè)用戶登錄請(qǐng)求中，只要誰先獲取到了 CPU 資源，誰就會(huì)先執(zhí)行，那么其他沒有獲取到 CPU 資源的請(qǐng)求就只能等待，這就是高并發(fā)環(huán)境下的資源搶占問題。

對(duì)于 CPU 來說，我們的一個(gè)用戶請(qǐng)求就代表著是一個(gè)計(jì)算機(jī)線程，比如我們現(xiàn)在有兩個(gè)用戶請(qǐng)求，即兩個(gè)線程來訪問我們的用戶登錄接口，我們分別使用線程 A 和線程 B 來命名。

假設(shè)我們的線程 A 先訪問到了我們的用戶登錄接口，而線程 B 比線程 A 晚 1 秒才訪問到，那么，當(dāng)我們的線程 A 在執(zhí)行業(yè)務(wù)邏輯時(shí)，線程 B 也會(huì)跟著執(zhí)行。

如果我們的線程 A 的用戶數(shù)據(jù)比較長(zhǎng)，需要執(zhí)行數(shù)據(jù)庫(kù)查詢所需的時(shí)間較長(zhǎng)，而線程 B 的用戶數(shù)據(jù)則比較端，需要執(zhí)行數(shù)據(jù)庫(kù)查詢所需的時(shí)間較短，那么，在統(tǒng)一時(shí)刻，可能晚于線程 A 才訪問到的用戶登錄接口線程 B 就會(huì)先于線程 A 執(zhí)行結(jié)束。

這就會(huì)造成：我們實(shí)際上是處理的線程 A 的業(yè)務(wù)邏輯，但是返回的時(shí)候卻將線程 B 的用戶數(shù)據(jù)進(jìn)行了返回，這也是高并發(fā)環(huán)境下非常容易出現(xiàn)的一個(gè)問題。

那么我們應(yīng)該怎么來優(yōu)化呢？

我們可以使用 RabbitMQ 來作為一個(gè)消息隊(duì)列，當(dāng)用戶請(qǐng)求來請(qǐng)求我們的服務(wù)時(shí)，我們可以將所有的用戶請(qǐng)求放入到我們的 RabbitMQ 消息隊(duì)列中，由于 RabbitMQ 消息隊(duì)列可以設(shè)置單條消息進(jìn)行消費(fèi)，所以，我們的用戶請(qǐng)求在處理時(shí)就會(huì)逐條進(jìn)行處理，不會(huì)出現(xiàn)上述所描述的問題。

我們來簡(jiǎn)單看下這種問題的優(yōu)化代碼，優(yōu)化代碼如下所示：

實(shí)現(xiàn)代碼：

public Response<User> userLogin(User user, HttpSession session){
    rabbitTemplate.convertAndSend("userLoginQueue", "user.login", user);
    // 獲取用戶數(shù)據(jù)并處理用戶登錄業(yè)務(wù)邏輯
}

代碼解釋：

第 2 行，我們使用了 rabbitTemplate 的 convertAndSend 方法，來將我們的用戶登錄數(shù)據(jù)發(fā)送到 RabbitMQ Server 中。

由于消費(fèi)者的實(shí)現(xiàn)比較復(fù)雜，考慮到篇幅原因，所以在這里代碼就沒有給出。

通過上述代碼，當(dāng)有用戶請(qǐng)求我們的用戶登錄接口時(shí)，會(huì)首先將該請(qǐng)求的用戶登錄數(shù)據(jù)存儲(chǔ)到我們的 RabbitMQ Server 中，存儲(chǔ)完成后，接著會(huì)從 RabbitMQ Server 中將該消息進(jìn)行取出并消費(fèi)，只有一條消息被消費(fèi)之后，RabbitMQ 才會(huì)繼續(xù)消費(fèi)下一條消息，這就保證了用戶請(qǐng)求的有序性，也就不會(huì)出現(xiàn)上述所提到的問題。

Tips: 我們?cè)趦?yōu)化用戶登錄功能時(shí)，一定要先理解我們所優(yōu)化問題的產(chǎn)生原因，這樣我們才能從根本上優(yōu)化這一問題。

4. 小結(jié)

本小節(jié)為同學(xué)們?cè)敿?xì)介紹了傳統(tǒng)的用戶登錄功能的基本概念和基本實(shí)現(xiàn)方法，以及在傳統(tǒng)的用戶登錄功能中所出現(xiàn)的可優(yōu)化的問題，針對(duì)出現(xiàn)頻率較高的問題，我們分別介紹了不同問題的不同優(yōu)化措施，并針對(duì)可以使用 RabbitMQ 進(jìn)行優(yōu)化的場(chǎng)景，我們使用了 Spring 生態(tài)中的 RabbitMQ 中的方法來進(jìn)行了優(yōu)化。