高併發系統設計的三大目標：高性能、高可用、可擴展
高併發：是指運用設計手段讓系統能夠處理更多的用戶併發請求，也就是承擔更大的流量。它是一切架構設計的背景和前提，脫離了它去談性能和可用性是沒有意義的。很顯然嘛，你在每秒一次請求和每秒一萬次請求，兩種不同的場景下，分別做到毫秒級響應時間和五個九（99.999%）的可用性，無論是設計難度還是方案的複雜度，都不是一個級別的。
性能和可用性：是我們實現高併發系統設計必須考慮的因素。
性能反應了系統的使用體驗，想象一下，同樣承擔每秒一萬次請求的兩個系統，一個響應時間是毫秒級，一個響應時間在秒級別，它們帶給用戶的體驗肯定是不同的。
可用性則表示系統可以正常服務用戶的時間。我們再類比一下，還是兩個承擔每秒一萬次的系統，一個可以做到全年不停機、無故障，一個隔三差五宕機維護，如果你是用戶，你會選擇使用哪一個系統呢？答案不言而喻。
可擴展性：它同樣是高併發系統設計需要考慮的因素。爲什麼呢？我來舉一個具體的例子。
流量分爲平時流量和峯值流量兩種，峯值流量可能會是平時流量的幾倍甚至幾十倍，在應對峯值流量的時候，我們通常需要在架構和方案上做更多的準備。這就是淘寶會花費大半年的時間準備雙十一，也是在面對“明星離婚”等熱點事件時，看起來無懈可擊的微博系統還是會出現服務不可用的原因。而易於擴展的系統能在短時間內迅速完成擴容，更加平穩地承擔峯值流量。
性能優化原則
- 首先，性能優化一定不能盲目，一定是問題導向的。脫離了問題，盲目地提早優化會增加系統的複雜度，浪費開發人員的時間，也因爲某些優化可能會對業務上有些折中的考慮，所以也會損傷業務。
- 其次，性能優化也遵循“八二原則”，即你可以用 20% 的精力解決 80% 的性能問題。所以我們在優化過程中一定要抓住主要矛盾，優先優化主要的性能瓶頸點。
- 再次，性能優化也要有數據支撐。在優化過程中，你要時刻了解你的優化讓響應時間減少了多少，提升了多少的吞吐量。
- 最後，性能優化的過程是持續的。高併發的系統通常是業務邏輯相對複雜的系統，那麼在這類系統中出現的性能問題通常也會有多方面的原因。因此，我們在做性能優化的時候要明確目標，比方說，支撐每秒 1 萬次請求的吞吐量下響應時間在 10ms，那麼我們就需要持續不斷地尋找性能瓶頸，制定優化方案，直到達到目標爲止。
性能的度量指標
- 平均值
顧名思義，平均值是把這段時間所有請求的響應時間數據相加，再除以總請求數。平均值可以在一定程度上反應這段時間的性能，但它敏感度比較差，如果這段時間有少量慢請求時，在平均值上並不能如實的反應。
- 最大值
這個更好理解，就是這段時間內所有請求響應時間最長的值，但它的問題又在於過於敏感了。比如一萬次響應中只有一次的響應時間是5秒，其他的都是毫秒級。最終最大值是5秒，但是僅僅出現了一次，就根據這個數據判斷性能的話就有失偏頗。
- 分位值
分位值有很多種，比如 90 分位、95 分位、75 分位。以 90 分位爲例，我們把這段時間請求的響應時間從小到大排序，假如一共有 100 個請求，那麼排在第 90 位的響應時間就是 90 分位值。分位值排除了偶發極慢請求對於數據的影響，能夠很好地反應這段時間的性能情況，分位值越大，對於慢請求的影響就越敏感。
高併發下的性能優化
1. 提高系統的處理核心數
提高系統的處理核心數就是增加系統的並行處理能力，這個思路是優化性能最簡單的途徑。
2. 減少單次任務響應時間
想要減少任務的響應時間，首先要看你的系統是 CPU 密集型還是 IO 密集型的，因爲不同類型的系統性能優化方式不盡相同。
CPU 密集型系統中，需要處理大量的 CPU 運算，那麼選用更高效的算法或者減少運算次數就是這類系統重要的優化手段。比方說，如果系統的主要任務是計算 Hash 值，那麼這時選用更高性能的 Hash 算法就可以大大提升系統的性能。
IO 密集型系統指的是系統的大部分操作是在等待 IO 完成，這裏 IO 指的是磁盤 IO 和網絡 IO。我們熟知的系統大部分都屬於 IO 密集型，比如數據庫系統、緩存系統、Web 系統。這類系統的性能瓶頸可能出在系統內部，也可能是依賴的其他系統，而發現這類性能瓶頸的手段主要有兩類。
第一類是採用工具，Linux 的工具集很豐富，完全可以滿足你的優化需要，比如網絡協議棧、網卡、磁盤、文件系統、內存，等等。這些工具的用法很多，你可以在排查問題的過程中逐漸積累。除此之外呢，一些開發語言還有針對語言特性的分析工具，比如說 Java 語言就有其專屬的內存分析工具。
另外一類手段就是可以通過監控來發現性能問題。在監控中我們可以對任務的每一個步驟做分時的統計，從而找到任務的哪一步消耗了更多的時間。這一部分在演進篇中會有專門的介紹，這裏就不再展開了。