性能優化目標

1、縮短響應時間

2、提高并發數(增加吞吐量)

3、讓系統處于合理狀態

圖片

性能優化手段

1、空間換時間

系統時間是瓶頸： 緩存復用計算結果，降低時間開銷，因為cpu時間較內存容量更加昂貴。

2、時間換空間   

• 數據大小是瓶頸
• 網絡傳輸是瓶頸，使用系統時間換取傳輸的空間，使用HTTP的gzip壓縮算法    
• app的請求分類接口,使用版本號判斷哪些數據更新,只下載更新的數據

3、找到系統瓶頸

• 分析系統的業務流程，找到關鍵路徑并分解優化
• 調用了多少RPC接口，載入多少數據，是用什么算法，非核心流程是否異步化。

性能優化層次

1、架構設計層次

如何拆分系統 如何使用部分系統整體負載更加均衡   充分發揮硬件設施性能優勢  減少系統內部開銷等

2、算法邏輯層次

關注算法選擇是否高效，算法邏輯優化，空間時間優化任務執行吃力，使用無鎖數據結構。

空間換時間:ThreadLocal

時間換空間：采用壓縮算法壓縮數據，更復雜的邏輯減少數據傳輸。

3、代碼優化層次

關注代碼細節優化,代碼實現是否合理,是否創建了過多的對象，循環遍歷是否高效,cache使用是否合理 

優化層次：從整理到細節，從全局角度到局部視角。

代碼優化層次(1)

• 循環遍歷是否合理高效,不要在循環里調RPC接口,傳輸分布式緩存 執行SQL等
• 先調用批量接口組裝好數據,再循環處理
• 代碼邏輯避免生成過多的對象和無效對象
• 輸出Log時候的log級別判斷  避免new無效對象
• ArrayList、HashMap初始容量設置是否合理
• 對數據對象是否合理重用 比如RPC查到的數據能復用則必須復用，根據數據訪問特性選擇合適數據結構,比如讀多寫少考慮  CopyOrWriteArrayList(寫時copy副本)，會否正確初始化數據，有些全局共享的數據，餓漢式模式，在用戶使用之前先初始化好。

代碼優化層次(2)

• CPU Cache結 構
• 速度越來越高：內存 - >L3->L2->L1多級緩存
• 本質上內存是一個大的一維數組，二維數組在內存中按行排列，先存放a[0]行，再存放a[1]行
• 第一種遍歷方式，是行遍歷，先遍歷完一行再遍歷第二行，符合局部性原理Cache Hit  (緩存命中率高)
• 第二種遍歷方式，是列遍歷，遍歷完第一列遍歷第二列，由于下一列和 上 一 列的數組元素在內存中并不是連續的，很可能導致Cache  Miss ( 緩 存 未 命 中 ) , CPU 需要去內存載入數據，速度較CPU    L1Cache的速度降低 了很多(主存100ns,L1  cache  0.5ns)

圖片

數據優化層次

select count(*)from table where add  time<"2017- 11-0623:59:59"  and  status=0  add  count in(1,2) ORDER BY id ASC;

代碼邏輯要適應數據變化的場景

圖片

圖片

圖片

算法優化邏輯層次

●用更高效的算法替換現有算法，而不改變其接口

● 增量式算法，復用之前的計算結果，比如一個報表服務，要從全量數據中生成報表數據量很大，但是每次增量的數據較少，則可以考慮只計算增量數據和之前計算結果合并，這樣處理的數據量就小很多

● 并發和鎖的優化，讀多寫少的業務場景下，基于CAS的LockFree比mutex 性能更好

● 當系統時間是瓶頸,采取空間換時間邏輯算法,分配更多空間節省系統時間

● 緩存復用計算結果，降低時間開銷， CPU時間較內存容量更加昂貴

● 當系統空間容量是瓶頸，采取時間換空間算法策略

● 網絡傳輸是瓶頸，使用系統時間換取空間的壓縮， HTTP的gzip 壓縮算法

● APP的請求分類接口，使用版本號判斷哪些數據更新，只下載更新的數據，使用更多的代碼邏輯處理更細粒 度的數據

● 并行執行，比如一段邏輯調用了多個RPC接口，而這些接口之間并沒有數據依賴，則可以考慮并行調用，降低響 應時間

● 異步執行，分析業務流程中的主次流程，把次要流程拆分出來異步執行，更進一步可以拆分到單獨的模塊去執行， 比如使用消息隊列，徹底和核心流程解耦，提高核心流程的穩定性以及降低響應時間

架構層次優化

● 系統微服務化

● 無狀態化設計，動態水平彈性擴展

● 調用鏈路梳理，熱點數據盡量靠近用戶

● 分布式Cache 、 多級多類型緩存

● 提前拒絕，保證柔性可用

● 容量規劃

● 分庫分表，讀寫分離，數據分片

案例：

圖片

Feed流系統分級緩存

讀多寫少、冷熱數據明顯，熱點數據緩存到調用鏈路更靠近用戶的地方

● L1緩存容量小負責抗最熱點的數據， L2緩存考慮目標是容量，緩存更大范圍的數據(一般用戶的timeline), 高熱點,數據單獨緩存，比如設置白名單，大V 的用戶數據放在L1緩存

● feed(關注的feed 、topic 的feed,一些運營的feed),前幾頁的訪問比例，前三頁占了90%+,針對這種業務特性，把 前面幾頁數據作為熱點數據提到L1 cache

Feed系統消息發布

寫擴散 (PUSH)

● 推送策略：拆分數據并行推，活躍用戶先推，非活躍用戶慢慢推

● 有 1w個用戶關注，發了一個feed,拆分成100份,每份100個并行推

● 1w個用戶里活躍的可能有2000個，活躍用戶先推，非活躍用戶慢慢推，保證活躍用戶體驗，非活躍用戶推 了很大概率也不看

讀擴散(PULL)

圖片

Feed系統存儲選型

圖片