說幾個拖垮系統的小細節！

時間 2019-11-13

標籤幾個拖垮系統細節简体版

原文原文鏈接

本文首發於我的微信公衆號《andyqian》,期待你的關注！

前言

有好幾天沒有更新了，期間確實比較忙些，以致於週末也沒休息。在這期間，感觸仍是蠻深的。如今碎片化的想法等整理好後，再以文章的形式分享出來。今天要說的是另一個主題。咱們在作系統設計時，時常會遇到系統中的一些小細節。成爲系統的瓶頸。活生生的拖垮系統。那麼究竟是誰拖垮了你的系統呢？這就是今天要說的主題。數據庫

萬惡的超時時間

這是一個容易忽略的小細節。但同時也是一個雷點。一不當心就會入坑。在超時時間方面，主要體如今: Http 接口請求時間，讀取時間等。服務之間調用超時時間等等。微信

試想一下: 咱們在請求時沒有設置超時時間會發生什麼app

以登陸爲例，以下圖所示:優化

流程：用戶點擊登陸後，你服務內部沒有設置請求超時時間。假設用戶服務不穩定，一致在等待用戶服務返回結果。此時線程一直掛起。致使客戶遲遲沒有接收到響應。嚴重時甚至致使app閃退。spa

慢SQL

在數據庫方面優化，在以前的MySQL系統文章中說過很多。主要分爲存儲引擎的選擇。以及SQL優化。在SQL優化方面有索引的合理選擇，在索引選擇方面，咱們能夠經過區分度來做爲索引字段選擇的依據。以及經過執行計劃做爲SQL優化的參考。其中還須要特別注意是《隱式類型轉換》。其實數據庫優化還包括不少。在此處說起的還僅僅只是應用層面上的優化。在必定量級的系統中。慢SQL經常是拖垮系統的主要緣由之一。.net

由大化小

這主要採用的是分而治之的思想。這種思惟咱們能夠應用到多種場景。例如: Http請求。數據庫請求。在進行數據操做時，咱們儘可能少用大事物。提交到數據庫中執行的SQL。儘可能簡潔，執行快。其實這也很容易明白。例如: 一共有400百斤糧食，你一次挑的話，確定是會被壓垮的。這時候。咱們能夠採用屢次少許的方法來進行。從而不會形成系統壓力。在系統中，也是一樣的道理。線程

小結

上面是系統中幾個常見且容易忽略的細節。經常也是拖垮系統的雷點。這裏作拋磚引玉。還有什麼坑了你們的系統的。歡迎你們在評論區留言。設計