過氣架構師現在談技術總是沒什麼底氣，倚老賣老一些，總覺得有些思路還是可以分享給初入行的年輕人。
很多時候，線上服務會遭遇到負載壓力，會導致崩潰。那麼很多時候，技術人員會說，這是請求過多導致的，這個理由很合理，畢竟伺服器資源有限，請求的響應能力也有限。
但關於請求，其實是可以繼續拆解和細分的。
通常，當我們面臨請求過多的問題，需要先明確，原始請求是多少，這是衡量負載支撐合理性的最核心指標。
那麼似乎很多人會認為，原始請求是不可優化的，不可裁剪的，其實未必，比如合理設定客戶端快取，在特定場景裡，可以讓原始請求頻次大幅度下降。
2、衍生請求，在執行原始請求的過程中，程式和系統所衍生出來的請求。
比如，你訪問乙個**，執行這個html的時候，會衍生出很多內嵌檔案的請求，比如css，比如js，比如圖示和logo，這裡其實也是有很多前端優化細節，當然，這是pc時代的傳統技能，現在基本無人關心了，舊文我記得提過，我也就不做無謂的炫技了。
比如，使用者請求乙個網頁的時候，後端**觸發了資料庫請求，快取請求，第三方介面請求等等，也都是衍生請求。
在物件導向程式設計風靡的時代，為了滿足一些通用性和普適性的訴求，一些不合理的封裝結構裡經常有大量冗餘的衍生請求，這會帶來負載的不合理開銷。而隨著硬體效能的逐漸提公升，傳統面向過程錙銖必較的優化手藝人越來越不受待見，到很像年輕人對老一代超級節儉的消費觀不以為然的那種感覺，這也是一種時代的進步吧。
如果不出問題，當然都不是問題，但如果頻繁出問題，其實這裡是有一些方**的。
常見方法1，請求解耦
某些請求連線在處理完之後，沒有及時關閉，而程式發生了另一種請求，那麼這時候，後者請求的阻塞會連帶前者請求的阻塞和崩潰。這是常見的一種請求的不當耦合。任何請求操作完成，及時關閉鏈結，是一種好習慣，可能說過一會還要請求這個鏈結，r如果中間過程簡單可控當然也可以，但如果中間有較為複雜的諸多其他請求，我建議過一會重新開啟請求都比持續鏈結要安全。
此外，如有可能，最好一次請求處理完所有與該請求目標有關的相關事務，不要拖拖拉拉的請求，而且中間夾雜著很多其他不同請求。
常見方法2，非同步處理
突然想起乙個流行詞，延時滿足。到還挺符合。
理論上，所有不需要實時反饋的資訊，都可以放在後台非同步處理，與前端請求脫鉤。
非同步處理可以解決大量衍生請求的問題，舉個例子，cnzz 2023年從各種草根站長的統計系統中脫穎而出，其實就是因為用了非同步處理的思想，統計**請求伺服器之後，不請求資料庫，不請求中間層，**只做日誌儲存，後台通過日誌做非同步統計，而且非同步處理可以基於某些策略，大量合併請求處理，這樣就極大降低了服務端的負載壓力。那有人會說，cnzz當時不是號稱實時統計麼？後台任務每分鐘處理，一分鐘的時延，使用者體驗不會有問題的。
有些時候，使用者感知是實時回饋的資料和資訊，可能並不一定是實時的，乙個可靠的非同步處理方案，完全可以做到只有1分鐘以內的延時響應。
常見方法3，隨動載入
資源預載入現在是很常見的，因為可以保持後續操作的流暢性，廣告的預載入，遊戲內容的預載入，等等等等。與之對應的就是隨動載入，也就是跟隨使用者的操作逐漸載入。隨動載入的好處是可以減少衍生請求，降低服務端負載，但缺點就是，操作體驗的流暢性會受到一定影響。
這裡不存在絕對的正確和錯誤，根據業務場景訴求斟酌選擇。
但其實存在一種兼顧的策略，在負載較輕的時候偏向於預載入，提公升使用者流暢**知，在負載較重超過閾值的時候，偏向於隨動載入，降低負載保護服務端穩定性。
常見方法4，中間層隔離
前端的所有衍生請求指向中間層，中間層調配請求並通過長連線與後端諸如資料庫，快取，佇列都系統通訊。中間層起到了彈性緩衝的作用，可以有效保護大量請求的過載，有些中間層如果設計合理，也可以將大量衍生請求快速合併處理，從而大幅度降低衍生請求的負載壓力。
3、雪崩效應導致的請求**
當系統遭遇一些故障的時候，因為某些請求被阻塞，帶來連鎖反應，相關大量請求被阻塞，系統負載或者一些請求鏈結數會呈現**式增長，很多時候，即便快速增加資源也無濟於事。微博的幾次熱點八卦事件引發的崩潰，都是這種雪崩效應的體現。
舉例來說，請求快取，如果找不到資料就請求資料庫，通常可能資料庫的溯源比例不超過30%，但因為快取被異常清理，所有快取請求被溯源，導致資料庫請求飆公升，直接崩潰，這就是一種典型的雪崩效應。
雪崩效應帶來的請求也分兩種，第一種是來自於系統層面的連鎖反應，a阻塞導致b阻塞，b又導致c阻塞，然後某些原因又導致阻塞被放大，最後形成全面的超級崩潰。第二種來自於使用者的操作反饋，使用者發現頁面無法開啟或者操作沒有響應，往往下意識的頻繁重新整理操作，這種使用者面對問題的頻繁操作，也會加劇雪崩效應。
那麼面對雪崩效應，其實也是有一些方**的。
常見方法1，降級響應
在服務雪崩的情況下，系統降級響應，保住核心業務，捨棄次要業務，直到系統恢復。
常見方法2，緊急阻斷
當發現負載超標時，應給予使用者友好提示，並自動拒絕接受重新整理和重複載入的請求。
常見方法3，單點隱患摘除
盡可能讓系統不存在單點依賴，每個單點都有自動容災備份及自動恢復的機制，一旦出現問題，備用系統可以自動上線應急，只要應急效率足夠高，那麼雪崩發生的機率就會極大降低。
其實前文的請求解耦，非同步處理和中間層隔離，不僅可以有效優化大量的衍生請求，對於防範雪崩效應也是非常有意義的，就不再贅述。
大體如此，那麼現在由於雲服務技術非常先進，很多新的架構方案把早年很多架構師需要自己處理的東西都系統化了，確實技術進展太快，很多領域我已經沒有話語權了。
那麼有一點要說明的就是，當雲服務資源在應急響應擴充套件的時候，不僅僅要關注各種資源的擴充，也要關注一些制約引數的擴充，這些其實往往隱藏很深，也是經常造成所謂「莫名其妙崩潰」，並且「加資源也解決不了」的現象。非常需要認真並且細心的了解系統層面及雲主機服務商各個層面的引數設計理念。
另外就是，如果原始請求增長有限，而系統請求急速激增的時候，前面的內容可以按部就班的核對一下。
大體如此吧。
分隔符後，繼續說明一下。
此外，我知識星球的年中福利課「談談職場溝通」，將在12月31日午夜下架。沒有看過的同學，請盡量抓緊時間。
授課形式是文字+語音，課程本身的內容是文字和語音基本一一對應，不過授課現場回答問題會臨時有一些插入文字可能沒有語音，或者臨時插入語音沒有文字。
為什麼不是直播課，其實文字+語音是提前備課的，而且素材組織是時間比較長的，聽過我課程的讀者知道，段落非常有邏輯性，並沒有什麼廢話和過場，其實整理的時候並不容易。而且錄音的時候，一段話一次錄製成功的比例並不高，不信讀者可以自己試試，寫一段比較規範的文字，然後一次性錄音不磕絆的成功率是多少。
Nginx Tomcat 做請求分發以及負載均衡
1 安裝tomcat 略 在 nginx 1.8.0 conf目錄下有乙個nginx.conf檔案，有如下 server error page 500 502503 504 50x.html location 50x.html listen 80 表示監聽80埠.server name localh...
Nginx Tomcat 做請求分發以及負載均衡
在 nginx 1.8.0 conf目錄下有乙個nginx.conf檔案，有如下 server error page 500 502503 504 50x.html location 50x.html location 實現 訪問本地的工程，訪問linux伺服器上的工程 在阿里上的虛擬主機 首先要修...
談談專案優化
最近系統的併發量加大，導致響應速度急速下降，專案採用ssh架構，在不更改源程式的情況下，對專案進行優化，顯著的提公升了系統效率，大致使用了以下幾項優化措施。1。檢查資料庫索引，這點很重要，對程式中的大部分where條件後的字段設定索引。2。資料庫採用的oracle9i，更改了資料庫的優化模式，設定o...