前言 插件化的需求主要源於對軟體架構靈活性的追求，特別是在開發大型、複雜或需要不斷更新的軟體系統時，插件化可以提高軟體系統的可擴展性、可定製性、隔離性、安全性、可維護性、模塊化、易於升級和更新以及支持第三方開發等方面的能力，從而滿足不斷變化的業務需求和技術挑戰。 一、插件化探索 在WPF中我們想要開 ...
1.描述一下伺服器配置:
一臺2c4g的centos,做api介面反代
一臺8c16g的windows 2019 作為實際伺服器,跑了iis,sql server,mongodb,redis
2.業務描述
2.0 伺服器分為兩個站點:importapi:用於處理數據導入,,,webapi:用於處理對用戶端的數據查詢
2.1 從數據源採集數據後,經過一系列的操作之後,寫入sql和mongodb,部分基礎信息會緩存在redis中,根據數據量的大小,從處理到寫入的整個流程時間在60ms-1200ms之間,平均每秒伺服器需要處理到2-3條數據,同一類型的數據使用隊列處理,避免併發寫入導致數據回跳或者出現臟數據的問題.
2.2 用戶web端,每秒定時通過介面讀取數據,並顯示界面上
3.使用到技術/類庫
Asp.net core 8,easycaching,freesql,redis
4.問題表現
當天晚上10點過後,突然mongodb,sqlserver和對外的webapi介面站點的進程突然cpu占用率暴漲,mongodb平均60-80%.webapi占用20%,sqlserver占用10%,記憶體占用了50%,,且遠程桌面操作不卡,webapi數據介面處理時間跟平時一樣200ms左右,但是數據不及時,通過日誌檢查的到,importapi站點原本處理時間上漲到6s-12s直接,導致了數據處理不及時,處理隊列積壓嚴重,從而導致了數據更新不及時.並且webapi介面項目不定時報"The wait queue for acquiring a connection to server 127.0.0.1:xxx is full".錯誤.從理論上說,我們的站點是小眾站點,業內人士使用,並不會出現突然涌進幾十倍的用戶的情況出現的
5.解決方式以及思路
從表現上看,是mongodb的壓力突然暴漲,導致寫入變慢,但是壓力來源是哪裡,由於還沒安裝監控面板,所以也沒辦法查看,因此只能按業務反向的思路去解決,總的解決用了一下幾個點
5.1 從導入的業務流程入手,儘量優化寫入以及數據分析操作所需要用的時間(之前幾天就想好的優化方案了,只是還沒上而已)
5.2 關掉mongodb client 的 關掉WithWriteConcern
5.3 在webapi介面項目,action上加入加上ResponseCache,過期時間3秒,(這裡的3秒主要是按業務上考慮的)
5.4 關掉反代nginx的日誌(減少點壓力,本來反代的伺服器性能就沒多高)
5.5 nginx開限流,10r/s/ip burst=20
5.6 準備一把刀(作用看後面)
以上處理後,importapi導入的時間降低到30ms-700ms,並且webapi輸出時間降低到50-300ms(緩存內50ms,緩存外300ms),mongodb的cpu占用降低到10%內,webapi占用5%下,,
6.最終原因分析
說起來,,問題其實很簡單,本來是只有一個前端站點把數據介面指向過來伺服器的,,前兩天遷移了另外一個站點,把數據介面也指向到這台介面伺服器,意思就是兩個web站點,使用同一套數據介面,,新接過來的站點,前端寫完代碼後,沒檢查,導致了一個致命的問題,由於前端使用vue,切換頁面的時候調用了暫停每秒一次的定時器,然後進入詳情頁後,開了一個新的定時器,也是每秒取一次另外一個介面的數據,,最大的問題就出現在,進入詳情頁後,列表頁的定時器調用關閉的函數報錯了,,實際定時器是沒關的,,這tm就吐血了,進去一次,開一個新的,後退到列表頁又開一個新的,,來回10次,意味著加了20個每秒請求一次的的定時器,,直接自己ddos自己.至於這個問題怎麼發現的,,,是解決完問題後,不死心,,去兩個站點里翻找問題,本來以為這個問題在很久之前測試的時候出現過一次,應該不會再出現的,,,結果,,,,
7. 總結,,本次問題出現從晚上10點,一步一步優化,12點多1點的時候基本代碼層面解決到1秒以內,,剩下的一些nginx的優化掃尾工作再花個不到一個鐘頭(開限流,關日誌之類的操作),順便幫前端的兩個站點的centos伺服器上,把nginx的靜態文件gzip跟緩存功能也打開了,清理了一下寫入到mongodb的日誌,至於那把刀是今天準備給前端的
---------------------------------------- 世事如棋，乾坤莫測，笑盡英雄
