本文是魚皮在騰訊實習(xí)期間，從零開始一周緊急上線百萬高并發(fā)系統(tǒng)的相關(guān)經(jīng)驗、思路及感悟，分享給大家。

花 5 分鐘閱讀本文，你將收獲：

1. 加深對實際工作環(huán)境、工作狀態(tài)的了解

2. 學(xué)習(xí)高并發(fā)系統(tǒng)的設(shè)計思路、技術(shù)選型及理解

3. 學(xué)習(xí)工作中對接多方的溝通技巧

4. 學(xué)會與測試打配合的技巧

5. 學(xué)習(xí)緊急事故的處理方式

6. 事后如何進行歸納總結(jié)

7. 感受筆者爆肝工作的痛苦與掙扎

前言

從年前開始和導(dǎo)師二人接手了一個緊急項目，年前加班做完一期后項目效果顯著，于是年后開工立刻加急開發(fā)二期，目標是一周上線。由于項目業(yè)務(wù)邏輯復(fù)雜、工期緊、人手缺、對接方多，難度很大，極具挑戰(zhàn)性，因此和導(dǎo)師二人開始了 007 的爆肝工作。

遠程辦公無疑為 007 無休工作制提供了有利條件，那段時間，我做夢都在敲代碼。

項目介紹

首先要介紹下負責(zé)的項目及系統(tǒng)。項目背景、業(yè)務(wù)等信息自然不能透露，這里剝離業(yè)務(wù)，僅介紹關(guān)鍵系統(tǒng)模型，如下圖：

如圖，我負責(zé)的是一個狀態(tài)流轉(zhuǎn)系統(tǒng)和查詢系統(tǒng)，以及它們依賴的數(shù)據(jù)庫服務(wù)。

狀態(tài)流轉(zhuǎn)系統(tǒng)的作用是按照邏輯修改數(shù)據(jù)庫中某條數(shù)據(jù)的狀態(tài)字段，并在修改成功后依據(jù)狀態(tài)向其他業(yè)務(wù)側(cè)發(fā)送通知。

查詢系統(tǒng)，顧名思義就是從數(shù)據(jù)庫中查詢數(shù)據(jù)，包括最基礎(chǔ)的鑒權(quán)、查詢等功能。

先分析一下系統(tǒng)中一些難點：

1. 查詢系統(tǒng)是一個高扇入服務(wù)，被其他各業(yè)務(wù)側(cè)調(diào)用，會存在三個問題：

高并發(fā)：將各業(yè)務(wù)側(cè)請求量聚集，經(jīng)評估，會產(chǎn)生百萬量級的高并發(fā)請求。

兼容性：如何設(shè)計一套 API，滿足各業(yè)務(wù)側(cè)需求的同時容易被理解。

對接復(fù)雜：要同時與多個業(yè)務(wù)側(cè)的同學(xué)溝通來討論接口，想想就是一件很復(fù)雜的事情。

2. 狀態(tài)流轉(zhuǎn)系統(tǒng)的業(yè)務(wù)邏輯相當(dāng)復(fù)雜。

3. 狀態(tài)流轉(zhuǎn)系統(tǒng)和查詢系統(tǒng)、其他業(yè)務(wù)側(cè)之間存在交互（比如互相發(fā)送通知和調(diào)用），對時延、容錯性、一致性的要求很高。

分析出了難點，在寫代碼之前，要先編寫可行的技術(shù)方案。

設(shè)計思路

在實際工作中，編寫詳細的技術(shù)方案是非常有必要的。優(yōu)秀的工程師會在技術(shù)方案中考慮到各種場景、評估各種風(fēng)險、工作量估時、記錄各種問題等，不僅幫助自己梳理思路、歸納總結(jié)，同時也給其他人提供了參照以及說服力（比如你預(yù)期7天上線，沒有方案誰信你？）。

根據(jù)二八定理，復(fù)雜的系統(tǒng)中，編寫技術(shù)方案、梳理設(shè)計思路的時間和實際敲代碼開發(fā)的時間比例為 8 : 2。

設(shè)計遵循的原則是?“貼合業(yè)務(wù)”，沒有最好的架構(gòu)，只有最適合業(yè)務(wù)的架構(gòu)。切忌過度設(shè)計！

此外，還要考慮項目的緊急程度和人力成本，先保證可用，再追求極致。

一些簡單的設(shè)計這里就略過了，下面針對系統(tǒng)難點和業(yè)務(wù)需求，列舉幾個重點設(shè)計及技術(shù)選型：

1. 高并發(fā)

提到高并發(fā)，大家首先想到的是緩存和負載均衡，缺一不可。

負載均衡說白了就是 “砸錢，加機器！”，但是為公司省機器、節(jié)約成本是每位后端工程師的信仰，這就要靠技術(shù)選型和架構(gòu)設(shè)計來實現(xiàn)了。目標是盡可能利用每臺機器的資源，抗住最大的并發(fā)請求。

選型如下：

編程框架：選擇輕量級的 Restful 框架 Jersey，搭配輕量級依賴注入庫 Guice

Web服務(wù)器：選擇高性能的輕量級 NIO 服務(wù)器 Grizzly

緩存：騰訊自研海量分布式存儲系統(tǒng) CKV+（支持Redis協(xié)議，有數(shù)據(jù)監(jiān)控平臺）

數(shù)據(jù)庫分庫分表：選用公司自研的基礎(chǔ)設(shè)施，不細說了

負載均衡：輕量級反向代理服務(wù)器 Nginx 和 L5 負載均衡，百萬并發(fā)需要增加十余臺機器

CDN 及預(yù)熱：能夠支持高效的文件下載服務(wù)

其中，緩存是抗住高并發(fā)流量的關(guān)鍵，須重點設(shè)計。

緩存方案

1. 數(shù)據(jù)結(jié)構(gòu)設(shè)計

用過緩存的同學(xué)都了解，關(guān)于緩存 Key 的設(shè)計是很重要的。根據(jù)業(yè)務(wù)來，保證緩存 key 之間不沖突、便于查找就好。此處我選擇請求參數(shù) + 接口唯一 id 來拼接 key。并且分頁查詢接口可復(fù)用全量查詢接口的緩存。

2. 緩存降級

找不到對應(yīng) key / redis 連接失敗時直接查庫。

3. 緩存更新

當(dāng)數(shù)據(jù)庫發(fā)生修改時，需要對緩存進行刪除。由于存在非必填的請求參數(shù)，因此緩存 key 可能是一個模糊值。比如有 a、b 兩個請求參數(shù)，key 可能為 “a”，也可能為 “ab”。

針對請求字段固定（所有字段必填）的接口，更新緩存時，直接拼接出唯一的 key 進行刪除即可。

而針對請求字段不固定（存在非必填字段）的接口，可使用 redis 的 scan 命令范圍掃描（不要用 keys 命令?。┗蛘咄ㄟ^循環(huán)拼接出所有可能的 key。比如使用 scan 命令清除所有 key 前綴為 user1 的緩存。

4. 緩存穿透

無論查詢出的列表是否為空，都寫入緩存。但在業(yè)務(wù)會返回多種錯誤碼時，不建議采用這種方式，復(fù)雜度高，成本太大。

2. 兼容性

兼容性主要考察接口的設(shè)計，為兼容多個業(yè)務(wù)側(cè)，需要將請求參數(shù)以及響應(yīng)參數(shù)設(shè)置的盡可能靈活。在設(shè)計接口時，切忌一定要和所有的業(yè)務(wù)側(cè)對齊，否則一個字段設(shè)計不當(dāng)可能導(dǎo)致滿盤皆輸！

這里有三個技巧：

1. 提供可訪問鏈接的文檔，供調(diào)用方即時查閱（比如騰訊文檔）。

2. 請求參數(shù)不能過多，且要易于理解，不能為了強制兼容而設(shè)置過于復(fù)雜的參數(shù)，必要時可針對某一業(yè)務(wù)側(cè)定制接口。

3. 響應(yīng)參數(shù)盡量多（多不是濫），要知道每次增加返回字段都要修改代碼，而適當(dāng)冗余的字段避免了此問題。

3. 消息通知

上面介紹難點時提到：狀態(tài)流轉(zhuǎn)系統(tǒng)與查詢系統(tǒng)、其他業(yè)務(wù)側(cè)存在互相發(fā)送通知的交互。當(dāng)狀態(tài)流轉(zhuǎn)時，需要通知其他業(yè)務(wù)，還要查詢系統(tǒng)立即更新緩存。對消息的實時性要求很高。

這里最初有兩種方案：

1. 各系統(tǒng)提供回調(diào)接口，用于接收通知。能保證實時性，但是各系統(tǒng)間緊耦合，不利于擴展。

2. 使用消息隊列，實現(xiàn)應(yīng)用解耦及異步消息。

最后還是采取了第二種方案，并選用騰訊自研的 TubeMQ（萬億級分布式消息中間件，已開源Apache孵化），原因如下：

1. 狀態(tài)流轉(zhuǎn)系統(tǒng)的通知數(shù)據(jù)之后可能存在其他消費方，使用消息隊列利于擴展，對代碼侵入性也少。

2. 消息隊列可持久化消息

3. TubeMQ 支持消費方負載均衡，性能高

4. TubeMQ 容量大，可存放萬億數(shù)量級消息

5. 支持公司自研組件，便于形成統(tǒng)一規(guī)范

在技術(shù)選型和確定方案時，不僅要關(guān)注當(dāng)前的業(yè)務(wù)需求，也要有一定的前沿視角。

4. 風(fēng)險評估

切忌，在選用中間件 / 框架前，要盡可能多的進行了解，評估其可能帶來的風(fēng)險。一般公司內(nèi)都有自己的知識庫，可以利用好內(nèi)部資源或者找谷歌度娘。

這里我評估了 TubeMQ 帶來的風(fēng)險，從消息可靠性、消息順序性、消息重復(fù)、監(jiān)控告警等多個角度進行了分析，還是發(fā)現(xiàn)了一些可能的風(fēng)險。比如當(dāng)消費方消費數(shù)據(jù)狀態(tài)改變的消息失敗時，緩存未被及時更新，導(dǎo)致數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一致。

那么，如何規(guī)避風(fēng)險呢？我從消息隊列生產(chǎn)方和消費方的角度設(shè)計了消息可靠性和數(shù)據(jù)一致性的解決方案。

解決方案

生產(chǎn)方消息可靠性：

1. Tube 可保證消息一定送達，發(fā)送失敗時會自動重發(fā)。

2. 發(fā)送消息結(jié)束時會觸發(fā)回調(diào)，回調(diào)里可判斷消息發(fā)送及確認狀態(tài)，可將發(fā)送失敗的消息放入隊列，下次發(fā)送優(yōu)先從隊列里取。

消費方消息可靠性和數(shù)據(jù)一致性：

1.消費失敗時進行最多三次重試

2.重試后仍消費失敗，則記錄日志，確保消息不丟失

3.通過定時任務(wù)讀取日志，嘗試再次消費失敗消息，并進行告警

開發(fā)過程

其實開發(fā)過程沒什么好說的，就是按照技術(shù)方案去敲代碼。

這里也有幾個小竅門：

1. 同時開發(fā)多個項目時，可以每個項目一個獨立 Git 分支，合并的時候分批合并，否則別人閱讀你提交的代碼時會非常累！

2. 給每個請求做一些打點數(shù)據(jù)上報，比如請求量、請求時間、失敗請求數(shù)，便于監(jiān)控統(tǒng)計。

3. 多記錄日志，詳細清晰的日志可以幫助我們快速定位故障

問題解決

很多問題在本地開發(fā)時是察覺不到的，在測試及線上環(huán)境才會被發(fā)現(xiàn)。問題解決的過程就像坐過山車，經(jīng)常的狀態(tài)是：測試 => 開發(fā) => 測試 => 上線 => 開發(fā) => 測試，循環(huán)往復(fù)。

兩個溫馨小貼士：

1. 遇到問題時，千萬不要慌，可以先深呼吸幾口氣，因為問題一定是可以解決的，解決不了那么你可能要被解決了！

2. 解決問題后，千萬別激動，可以先深呼吸幾口氣，因為你還會產(chǎn)生新的問題，而且往往新問題更嚴重！

下面分享一些讓魚皮印象深刻的問題。

1. 事務(wù)提交時報錯？

原因：事務(wù)中調(diào)用的函數(shù)里也有事務(wù)，因此事務(wù)里套了事務(wù)，破壞了隔離性。

解決：修改代碼，保證事務(wù)隔離性。

2. 依賴包存在，項目啟動卻報錯？

原因：存在多版本 jar 包，導(dǎo)致 Java 代碼使用反射機制動態(tài)生成類時不知道使用哪個 jar 包里的類。

解決：刪掉多余版本 jar 包。

3. 緩存未即時更新

原因：經(jīng)排查，是由于實際的緩存 key 數(shù)量可達千萬級，導(dǎo)致更新緩存時使用 scan 命令掃描的效率過低，長達20多秒！

解決：修改更新緩存的方案，不再使用 scan 命令，而是在業(yè)務(wù)代碼中拼湊出所有可能的 keys，依次刪除。

以為這個問題這樣就結(jié)束了？不要忘記上面的小貼士：

“解決問題后，千萬別激動，可以先深呼吸幾口氣，因為你還會產(chǎn)生新的問題，而且往往新問題更嚴重！”

4. 緩存仍未即時更新？

原因：某業(yè)務(wù)側(cè)要求數(shù)據(jù)強一致性，緩存和數(shù)據(jù)庫中的狀態(tài)必須完全一致！而緩存雖然是毫秒級更新，但無法做到實時一致。

解決：為該業(yè)務(wù)側(cè)定制一個接口，該接口不查詢緩存，直接查數(shù)據(jù)庫，保證查到的數(shù)據(jù)一定是最新值。

5. 請求卡死

服務(wù)運行一段時間后，發(fā)現(xiàn)所有的請求都被阻塞了！心臟受不了。

原因：使用 jstack 打印線程信息后分析 thread_dump 文件，發(fā)現(xiàn)是由于緩存類庫 Jedis 未手動釋放連接導(dǎo)致連接數(shù)耗盡，導(dǎo)致新的請求線程會不斷等待 Jedis 連接釋放，從而卡死。

解決：補充釋放 Jedis 連接的代碼即可。

6. 線上環(huán)境分析日志時突然告警，磁盤 IO 占用超過 99%！

原因：誤用 cat 命令查看未分割的原始日志文件，由于日志文件太大（幾十 GB），導(dǎo)致磁盤 IO 直接刷爆！

解決：使用 less、tail、head等命令代替 cat，并刪除已備份的大日志文件。

7. 進程閃退

排查：通常 JVM 進程閃退是有錯誤日志的，但是并沒有找到，排查陷入絕境。沒辦法，只能祈禱問題不再復(fù)現(xiàn)。后來問題真的沒出現(xiàn)過了，謝謝！

原因：后來，經(jīng)詢問，是有人手動 kill 掉了這個進程。好的，***。

8. 線上環(huán)境的消息通知發(fā)送成功了，怎么沒有預(yù)期的數(shù)據(jù)更新效果？

定位思路：先看消息是否被消費，再看對消息的處理是否正確。

排查：查看線上日志，發(fā)現(xiàn)消息并未被消費；但是查看監(jiān)控界面，發(fā)現(xiàn)消息被測試環(huán)境的機器消費了！

原因：由于測試環(huán)境和線上環(huán)境屬于同一個消費組，當(dāng)消息到達時，同一個消費組只有一個消費者能夠成功消費該消息，被測試環(huán)境消費掉了，導(dǎo)致線上環(huán)境數(shù)據(jù)沒更新。

發(fā)現(xiàn)這個問題的時候，已經(jīng)是上線前一天的深夜。再申請一個消費組已經(jīng)來不及了，情急之下，只能先下掉測試環(huán)境的服務(wù)。第二天申請好消費組后，根據(jù)環(huán)境去區(qū)分使用哪個消費組就可以了，這樣每個消費組都會獨立消費消息，成功避免了消息競爭。

9. 報告！流量太大，撐不住??！

原因：機器不夠，需進行緊急擴容

解決：緊急新申請了 10 臺機器，完成初始化配置，成功部署新機器后，成功增大了并發(fā)度。

小技巧：多個機器做相同操作時，有兩種快捷的做法。

1. 利用 SSH 連接工具自帶的并行操作功能，自動給所有機器鍵入命令（ XShell 軟件支持）

2. 配置好一臺機器后，可使用 rsync 命令同步配置至其他機器

10. 上線前一天你跟我說接口設(shè)計有問題？

原因：溝通出現(xiàn)嚴重問題！

工作中，一些同事因為自身業(yè)務(wù)繁忙，可能在核對接口設(shè)計方案的時候沒有注意。等他們忙完了，會反復(fù) @ 你、私聊你詢問。我們一定不要這樣！

解決：緊急電話會議，拉群核對方案

11. 線上出 bug 了！

線上出 bug，是一件很大的事，必須緊急響應(yīng)。在夢里也得給我爬起來！

原因：測試環(huán)境和線上環(huán)境未必完全一致，且測試環(huán)境未必能測出所有問題。因此驗證時通常需要預(yù)發(fā)布環(huán)境，數(shù)據(jù)使用線上數(shù)據(jù)，但卻是獨立的服務(wù)器，保證不影響線上。

解決：緊急排查定位問題，三分鐘成功修復(fù)！

修復(fù) bug 有一定的技巧，分享下個人的排錯路徑：

截圖 / 問題 => 請求 => bug 是否可復(fù)現(xiàn)，和測試緊密配合 => 數(shù)據(jù) => 數(shù)據(jù)源（真實數(shù)據(jù)與接口數(shù)據(jù)是否一致） => 數(shù)據(jù)處理

解釋一下：

通常發(fā)現(xiàn)問題的是運維、用戶或者測試，他們會拋出一個問題或者問題的相關(guān)的截圖，這時，我們要快速想到這個問題對應(yīng)的功能（即對應(yīng)的請求/接口），然后讓問題描述者盡可能多的提供信息（比如請求參數(shù)、問題時間等）。

如果問題時間較久，看日志及監(jiān)控不易排查，可以詢問是否可以造一個復(fù)現(xiàn)該問題的case，這樣只需觀察最新的日志即可，方便排錯。

定位到請求后，我們要分析請求及響應(yīng)的哪些數(shù)據(jù)是異常的，即定位關(guān)鍵數(shù)據(jù)，然后定位數(shù)據(jù)來源（是從數(shù)據(jù)庫查的，還是從緩存查的），并觀察響應(yīng)數(shù)據(jù)與真實數(shù)據(jù)源是否一致。如果不一致，可能是業(yè)務(wù)邏輯中對數(shù)據(jù)的處理出現(xiàn)了問題，再進一步去做分析。

高效溝通建議：描述問題，盡量用數(shù)據(jù)說話，給出截圖的同時，要提供完整的數(shù)據(jù)、請求等信息，有助他人分析。

12. 線上出現(xiàn)部分錯誤數(shù)據(jù)

這是一個可以預(yù)見的問題。還好已經(jīng)在項目中配置了郵件告警，能夠報告錯誤數(shù)據(jù)的信息，錯誤數(shù)據(jù)量也不大。

解決：修復(fù)導(dǎo)致錯誤數(shù)據(jù)的 bug 后，編寫程序循環(huán)所有錯誤信息并生成請求代碼，然后手動執(zhí)行請求代碼，刷新線上不同步數(shù)據(jù)即可。

建議：設(shè)計時還是要盡可能考慮到風(fēng)險，可以按照問題的嚴重程度做分級報警策略（短信 > 郵件 > 通訊軟件）。

13. 線上機器 OOM！

上線三天后發(fā)現(xiàn)的問題，部分線上機器竟然出現(xiàn)了OOM（堆內(nèi)存溢出）的情況，導(dǎo)致服務(wù)不可用。經(jīng)排查，是使用的第三方中間件的當(dāng)前版本存在 bug， 所以說在使用組件前要充分調(diào)研和風(fēng)險評估，選擇正確的版本。

血淚教訓(xùn)

1. 有問題一定盡可能在測試環(huán)境去解決，否則線上出問題對心臟很不友好。

2. 不要盲目樂觀，以為上線就沒問題，要多驗證，保持警惕。

3. 使用第三方依賴時，一定要嚴格核對依賴版本號，確保穩(wěn)定版本。使用老版本或版本不一致可能導(dǎo)致嚴重 bug！

上線后如果發(fā)現(xiàn)問題，會經(jīng)歷如下流程，我稱它為 hapy 流程。

比如當(dāng)發(fā)現(xiàn) DB 服務(wù)的 bug 后，你只需要改 DB 服務(wù)的一行代碼。然而還要做：

1. 修改DB服務(wù)的一行代碼

2. 跑單元測試

3. DB服務(wù)打成依賴包

4. 修改“狀態(tài)流轉(zhuǎn)系統(tǒng)”、“查詢系統(tǒng)”對DB服務(wù)的依賴包（改動版本號/更新本地緩存拉取最新包）

5. 重新發(fā)布“狀態(tài)流轉(zhuǎn)系統(tǒng)”、“查詢系統(tǒng)”至測試環(huán)境

6. 可能還要重新交給測試的同學(xué)進行回歸測試

7. 測試通過，再次提交“狀態(tài)流轉(zhuǎn)系統(tǒng)”、“查詢系統(tǒng)”的代碼，發(fā)起 CR（代碼審查）

8. 找同事或 Leader 讀代碼，通過 CR

9. 合并分支

10. 發(fā)布 “狀態(tài)流轉(zhuǎn)系統(tǒng)”、“查詢系統(tǒng)” 至線上環(huán)境，每發(fā)一臺機器，都要進行一次驗證（滾動部署）。

11. 再次發(fā)現(xiàn)新的bug

這是一件惡心到爆炸的事情，但是在第 2、6、8 步驟時，是存在空余等待時間的。這時我們可以做做其他工作，記錄一下工作內(nèi)容、問題等。

總結(jié)

首先總結(jié)一下這個項目各階段的耗時：

理解需求：5%

開發(fā)：15%

溝通確認問題：30%

測試及驗證：30%

上線及驗證：20%

其中，修復(fù) bug 貫穿后面的幾個流程，大概占了總時間的60%。

項目過程存在的問題：

1. 前期未參與需求評審，了解的信息較少。

2. 上線前一天晚上，竟然還在臨時對齊接口？這是在溝通方案階段應(yīng)該確認好的。

3. 大約 80% 的時間花在溝通、查詢數(shù)據(jù)、提供數(shù)據(jù)及驗證。

4. 自己沒測試完，就開始串測，導(dǎo)致同一個 bug 被多方發(fā)現(xiàn)，反復(fù) @，導(dǎo)致改 bug 效率低下。

5. 對自研中間件的不熟悉，導(dǎo)致花費的時間成本較高。

6. 全局觀還不夠，不能提前預(yù)見到一些可能的問題。

7. 對中間件調(diào)研不夠，在最初未核對依賴版本號導(dǎo)致線上機器 OOM。

自我感覺良好的地方：

1. 和測試同學(xué)配合緊密，互相體諒，測試效率較高

2. 為查詢系統(tǒng)編寫了詳細的接口文檔，上傳至公司知識庫供實時查閱

3. 最快 3 分鐘緊急修復(fù)線上 bug

4. 最快 30 分鐘從接受需求到上線

5. 在發(fā)現(xiàn)中間件問題時，即時和對接方溝通，設(shè)計出了對其無任何影響的低成本解決方案

6. 積極幫助其他同學(xué)查詢數(shù)據(jù)，排查問題

7. 編寫腳本高效解決部分錯誤數(shù)據(jù)

成長與收獲：

1. 抗壓熬夜能力 ↑

2. 設(shè)計思維能力 ↑

3. 溝通能力 ↑

4. 解決問題能力 ↑

5. 高級命令熟悉度 ↑

6. 中間件熟悉度 ↑

7. 集群管理能力 ↑

8. 拒絕需求能力 ↑

9. 吐槽能力 ↑

10. 吹 ? 能力 ↑

后續(xù)

項目上線后，通過總結(jié)復(fù)盤，發(fā)現(xiàn)了項目中值得優(yōu)化的地方，也思考到了一些更健全的機制，將逐漸去實現(xiàn)。比如：

1. 兩個系統(tǒng)中有部分相同的配置

目前采用復(fù)制粘貼的方式去同步相同的配置，這種方式的優(yōu)點是比較簡單。但缺點也很明顯，如果一個系統(tǒng)的配置改了，而忘了修改另一個系統(tǒng)的配置，就會出現(xiàn)錯誤。

事實上，可以引入一個配置中心，集中管理多個系統(tǒng)的配置文件，并且支持手動修改、多環(huán)境、灰度、配置版本回退等功能。

可以采用阿里的 Nacos 或攜程的 Apollo，提供了界面來管理配置。

2. 曾經(jīng)的進程閃退問題，必須重視！

無法保證進程不閃退，但是可以對進程實時監(jiān)控，并自動對閃退進程進行重啟。

實現(xiàn)方式有兩種：

1. 使用工具，例如 supervisor 或 monit，可以對進程進行管理和閃退重啟

2. 編寫 shell 腳本，再通過定時任務(wù)，實現(xiàn)周期性觀察進程狀態(tài)及重啟。推薦將定時任務(wù)接入分布式任務(wù)調(diào)度平臺，尤其當(dāng)定時任務(wù)很多時，進行可視化的管理和方便的控制調(diào)度是必要的！

3. 消息隊列可靠性保障

1. 消息重傳機制：如方案所說，設(shè)計重傳隊列，再次發(fā)送時優(yōu)先取重傳隊列中的消息發(fā)送。但注意要避免隊列無限重傳，須給每個消息設(shè)置重傳次數(shù)閾值。

2. 郵件告警：如果消息重傳次數(shù)超過閾值，直接發(fā)送郵件告警，不再將該消息入隊。

工作真是簡單而不簡單，誰說后端只是 CRUD（增刪改查）？

后臺回復(fù)?學(xué)習(xí)資料?領(lǐng)取學(xué)習(xí)視頻

如有收獲，點個在看，誠摯感謝