原文連接: 何曉東 博客前端
我的理解高併發系統主要在於:機器資源的合理分配和性能的壓榨,代碼質量,及維護高併發系統在請求峯值的時候,系統中有機器宕機時整個系統的可用性。 核心是提升吞吐,下降響應時間。
還有幾個觀點是:高併發技術能夠有,可是不少公司沒有高併發場景。越是沒有高併發場景的公司越願意問高併發的問題,是爲了考察面試者對於行業尖端技能的學習仍是爲了壓價?而有高併發場景的公司通常很在意基礎,基礎好的人寫出來的代碼比爛代碼性能強一點的話,併發時會嚴重放大提高的這一點性能。git
至於在有併發場景以前的優化網站性能,多數狀況會依賴:1. 前端資源 CDN 化,公用的資源編譯壓縮,同時使用瀏覽器自身緩存,提高資源加載速度,也減小訪問一個頁面給此域名帶來不少的請求。 2. 優化 SQL 操做,95%+ 的問題是 sql 優化能夠提高的,對應也有代碼中的魔性操做,帶來的執行效率的問題。github
不必定每一個場景都會產生高併發,不要爲了高併發而盲目的設計,過分設計帶來的問題遠比意料以外的高併發要多不少,依賴於具體場景和行爲進行分析,一個購物類網站,搶購場景,會觸發不少的讀取商品詳情,計算庫存等操做,並且不須要每一個請求都到達支付頁面,也不會在網站主頁帶來不少的請求,因此須要針對搶購場景進行優化,而不是巨大的支付流程進行優化,固然商品數量多和用戶多的狀況,才須要也優化一下支付流程。面試
拋開場景,不談流量的盲目高併發設計,通常是過分設計,將來維護臃腫而複雜的代碼會懲罰你當初的過分設計。sql
基本是被人刷了,或者比預估的狀況要多了幾倍,纔有這種狀況,前者可能性很大,最近這兩年的金融網站,區塊鏈,xx幣網站,基本會被羊毛黨盯上,沒作好訪問防做弊,或者被對手 ddos 攻擊,都會形成高併發中網站癱瘓,清洗流量通常就能夠的,不要讓辣雞流量貫穿整個業務。高併發會帶來網站請求慢,但網站請求慢不必定是高併發了,對症下藥。數據庫
若是是網紅帶貨什麼的,給網站帶來高併發了,這種狀況下能夠在提早流量上作些手腳,例如:1. 用消息隊列排隊流量,例如猴王網站的搶購 2. 採用一些高端點的驗證碼,讓一些秒殺搶購的機器號被過濾出去,儘可能不影響真實用戶的搶購結果 3. 分層過濾,例如靜態資源放在 CDN 上,NGINX 層面使用自身的緩存,根據路由緩存基礎數據,其餘動態數據再讀寫數據庫,而不是每一個請求都通過總體的業務,這樣帶來的壓力太大了,並且也不值得。segmentfault
能夠將高併發的業務部分分離到單獨的服務器。這種狀況下可以避免這部分業務帶來機器性能的消耗,從而影響整個項目的穩定性,這樣的結果不太好的。也能夠預先將熱數據放到緩存中,提升讀寫效率,也能讓 MySQL 比較穩定,通常狀況下能有高併發的網站,數據量也很多,舉例某個電商網站,可能有 100w 商品數據,但你們搶購的是今天熱推的 10 個商品,將這十個數據提取放到緩存中,而不是每次去數據庫中查詢,固然 MySQL 設置合理的話,自身的 buffer pool 也能搞定這些熱數據緩存。這樣至關於將這 10 條數據隔離出來,而不是影響到總體數據。關於熱點數據的發現,還有一些高端的是從 NGINX 訪問日誌層面實時分析,聽說淘寶這種是這樣的,實時發現訪問不少的路由,分析路由獲取到對應的商品數據,放到緩存中,減輕服務器壓力。瀏覽器
穩定性不光存在於業務機器層面,也多是網絡寬帶不夠,或者程序在磁盤寫日誌的時候遇到瓶頸,或者內存不夠,致使可用緩存空間很小。這些在測試和計算層面須要注意的問題,也會影響總體穩定性和性能的,應該提早解決。例如秒殺系統須要關注 CPU,併發讀須要關注緩存,靜態資源多的也須要考慮寬帶。緩存
簡單能夠是壓測關鍵業務部分,簡單的查詢通常不會帶來問題,這個頁面的靜態資源太多,同時都在統一個域名下的話,至關於在現有併發的數量上加了更多,這很是不利,對於瀏覽器的加載也是不利的,簡單業務也會體驗不好。壓力測試應當遵循慢慢提高流量的方式,併發量和響應時間並非等比例上漲的,慢慢提高併發量的測試,會展現代碼的瓶頸部分在哪,而後在去解決和提高。測試也能夠安全
在基礎的併發測試以外,還有在正是服務器上的全鏈路壓力測試,爲了防止和真實數據衝突,能夠將請求中加上額外的標記,或者針對特定的用戶賬號測試,在數據中體現這部分額外標記,測試完畢以後將數據刪除。
同時,不要高併發的主要業務一直佔用機器的 100% 的運算能力,這樣總體邏輯和請求支持已經到了極限,基本再高一點就會形成問題,應該儘可能讓業務只佔用機器 60-70% 的運算能力,留出一部分的餘地,防止意外。
高併發 + 高可用就須要考慮到崩潰的狀況怎麼處理,實時監控確定須要有,而後在崩潰以前,能夠採起幾個措施:1. 從 NGINX 層面限制單個 IP 單位時間內請求頻率和次數,屏蔽掉機器刷的可能性,從而不影響正常訪問。 2. 切記高併發 + 高可用不能夠用單點系統,例如不能由於熱數據少而就用一臺 Redis 服務器,或者更狠的直接本機緩存,一旦系統崩潰,至關於觸發連鎖反應,連保存現場和恢復都很難。 3. 提早設計兜底方案 ① 降級,例如商品詳情頁面不展現推薦商品,或者減小推薦商品展現數量等, ② 限流,不讓更多流量涌入,能減小不少壓力 ③ 過載臨界點拒絕服務,這個是最壞的狀況,直接阻斷壓垮系統的最後一個流量。
參考連接: