1、高併發系統設計的三大目標：高性能、高可用、可擴展
- 性能，反應了系統的使用體驗，例如，同樣承擔每秒一萬次請求的兩個系統，一個響應時間是毫秒級的，一個是秒級別，這樣它們帶給用戶的體驗肯定不同的。
- 可用性表示系統可以爲正常服務用戶的時間。類比一下，還是兩個承擔每秒一萬次請求的兩個系統，一個系統可以全年不停機、無故障；另一個隔三差五的宕機維護
- 可擴展性，流量一般分爲平時流量和峯值流量，峯值流量可能會是平時流量的幾倍甚至幾十倍，在應對峯值流量時，就要在架構和方案上做更多的準備。比如雙十一前的準備，明星事件等。易於擴展的系統能在較短的時間內迅速完成擴容，更加平穩的承擔峯值流量。
2、性能優化的原則
- 性能優化一定不能盲目，一定是問題導向的。如果脫離了實際問題，盲目的提早優化會增加系統的複雜度，並浪費人力，這種是不可取的。
- 性能優化也遵循”八二原則“，即你可以用 20%的精力去解決 80% 的性能問題。所以我們在優化過程中需要抓住主要矛盾，優化主要的性能瓶頸
- 性能優化需要有數據支撐。即瞭解你的優化讓響應時間減少了多少，提升了多少吞吐量。
- 性能優化的過程是持續的，需要不斷的解決性能瓶頸。
3、性能的度量指標
我們需要有度量的指標，有了數據才能明確目前存在的性能問題，也能夠用數據來評估性能優化的效果。
- 平均值
- 最大值
- 分位值
分位值有很多種，比如 90 分位、95 分位、75 分位。以 90 分位爲例，我們把這段時間請求的響應時間從小到大排序，假如一共有 100 個請求，那麼排在第 90 位的響應時間就是 90 分位值。分位值排除了偶發極慢請求對於數據的影響，能夠很好地反應這段時間的性能情況，分位值越大，對於慢請求的影響就越敏感。
響應時間控制在多久比較合適呢？
從用戶體驗的角度來說：
- 200ms是第一個分界點，感覺不到，體驗極好
- 1s是一個分界點，可以感覺到有延遲，但可以接受
- 超過1s，有明顯的等待，基本不能接受
健康系統的 99 分位值的響應時間通常通知在 200 ms 之內，不超過 1s 的請求佔比要在 99.99% 以上。
4、高併發下的性能優化
1、提升系統的處理核心數
增加系統的並行處理能力
2、減少單次任務的響應時間
先看系統是 CPU 密集型還是 IO 密集型
CPU密集型系統中，需要處理大量的 CPU 運算，那麼選用更高效的算法或者減少運算次數就是這類系統重要的優化手段。
IO 密集型系統指的是系統的大部分操作是在等待 IO 完成，
-
磁盤 IO
-
網絡 IO
我們熟知的系統大部分都屬於 IO 密集型，比如數據庫系統、緩存系統、Web 系統。這類系統的性能瓶頸可能出在系統內部，也可能是依賴的其他系統，而發現這類性能瓶頸的手段主要有兩類：
-
採用工具
Linux 的工具集很豐富，完全可以滿足你的優化需要，比如網絡協議棧、網卡、磁盤、文件系統、內存，等等
-
通過監控來發現性能問題。
在監控中我們可以對任務的每一個步驟做分時的統計，從而找到任務的哪一步消耗了更多的時間。
5、總結
- 數據優先，你做一個新的系統在上線之前一定要把性能監控系統做好；
- 掌握一些性能優化工具和方法，這就需要在工作中不斷的積累；
- 計算機基礎知識很重要，比如說網絡知識、操作系統知識等等，掌握了基礎知識才能讓你在優化過程中抓住性能問題的關鍵，也能在性能優化過程中游刃有餘