系統設計目標(一):如何提升系統性能?

提到互聯網系統設計,你可能聽到最多的詞兒就是“三高”,也就是“高併發”“高性能”“高可用”,它們是互聯網系統架構設計永恆的主題。本篇文章主要是闡述高併發系統設計的含義,意義以及分層設計原則,接下來,帶你整體瞭解一下高併發系統設計的目標,然後在此基礎上,進入今天的話題:如何提升系統的性能?

高併發系統設計的三大目標:高性能、高可用、可擴展

高併發,是指運用設計手段讓系統能夠處理更多的用戶併發請求,也就是承擔更大的流量。它是一切架構設計的背景和前提,脫離了它去談性能和可用性是沒有意義的。很顯然嘛,你在每秒一次請求和每秒一萬次請求,兩種不同的場景下,分別做到毫秒級響應時間和五個九(99.999%)的可用性,無論是設計難度還是方案的複雜度,都不是一個級別的。而 性能和可用性,是我們實現高併發系統設計必須考慮的因素。另一個耳熟能詳的名詞叫 “可擴展性”,它同樣是高併發系統設計需要考慮的因素。

流量分爲 平時流量 和 峯值流量 兩種,峯值流量可能會是平時流量的幾倍甚至幾十倍,在應對峯值流量的時候,我們通常需要在架構和方案上做更多的準備。這就是淘寶會花費大半年的時間準備雙十一,也是在面對“明星離婚”等熱點事件時,看起來無懈可擊的微博系統還是會出現服務不可用的原因。而易於擴展的系統能在短時間內迅速完成擴容,更加平穩地承擔峯值流量。

性能優化原則

首先,性能優化一定不能盲目,一定是問題導向的。脫離了問題,盲目地提早優化會增加系統的複雜度,浪費開發人員的時間,也因爲某些優化可能會對業務上有些折中的考慮,所以也會損傷業務。
其次,性能優化也遵循 “八二原則”,即你可以用 20% 的精力解決 80% 的性能問題。所以我們在優化過程中一定要抓住主要矛盾,優先優化主要的性能瓶頸點。

再次,性能優化也要有數據支撐。在優化過程中,你要時刻了解你的優化讓響應時間減少了多少,提升了多少的吞吐量。

最後,性能優化的過程是持續的。高併發的系統通常是業務邏輯相對複雜的系統,那麼在這類系統中出現的性能問題通常也會有多方面的原因。因此,我們在做性能優化的時候要明確目標,比方說,支撐每秒 1 萬次請求的吞吐量下響應時間在 10ms,那麼我們就需要持續不斷地尋找性能瓶頸,制定優化方案,直到達到目標爲止。

高併發下的性能優化

假如說,你現在有一個系統,這個系統中處理核心只有一個,執行的任務的響應時間都在10ms,它的吞吐量是在每秒 100 次。那麼我們如何來優化性能從而提高系統的併發能力呢?主要有兩種思路:一種是提高系統的處理核心數,另一種是減少單次任務的響應時間。

1. 提高系統的處理核心數

提高系統的處理核心數就是增加系統的並行處理能力,這個思路是優化性能最簡單的途徑。拿上一個例子來說,你可以把系統的處理核心數增加爲兩個,並且增加一個進程,讓這兩個進程跑在不同的核心上。這樣從理論上,你係統的吞吐量可以增加一倍。當然了,在這種情況下,吞吐量和響應時間就不是倒數關係了,而是:吞吐量 = 併發進程數 / 響應時間。

2. 減少單次任務響應時間

想要減少任務的響應時間,首先要看你的系統是 CPU 密集型還是 IO 密集型的,因爲不同類型的系統性能優化方式不盡相同。

CPU 密集型系統中,需要處理大量的 CPU 運算,那麼選用更高效的算法或者減少運算次數就是這類系統重要的優化手段。比方說,如果系統的主要任務是計算 Hash 值,那麼這時選用更高性能的 Hash 算法就可以大大提升系統的性能。發現這類問題的主要方式,是通過一些 Profile 工具來找到消耗 CPU 時間最多的方法或者模塊,比如 Linux 的 perf、eBPF等。

IO 密集型系統指的是系統的大部分操作是在等待 IO 完成,這裏 IO 指的是磁盤 IO 和網絡IO。我們熟知的系統大部分都屬於 IO 密集型,比如數據庫系統、緩存系統、Web 系統。這類系統的性能瓶頸可能出在系統內部,也可能是依賴的其他系統,而發現這類性能瓶頸的手段主要有兩類。

找到了系統的瓶頸點,我們要如何優化呢?優化方案會隨着問題的不同而不同。比方說,如果是數據庫訪問慢,那麼就要看是不是有鎖表的情況、是不是有全表掃描、索引加得是否合適、是否有 JOIN 操作、需不需要加緩存,等等;

個人總結

有時候你在遇到性能問題的時候會束手無策,基本的思考點有以下:

  • 數據優先,你做一個新的系統在上線之前一定要把性能監控系統做好;
  • 掌握一些性能優化工具和方法,這就需要在工作中不斷的積累;
  • 計算機基礎知識很重要,比如說網絡知識、操作系統知識等等;
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章