01高併發系統：通用設計方法
1 應對大流量的方法
1.1 橫向擴展
分而治之的思想，採用分佈式部署的方式把流量分開，讓每個服務器都承擔一部分併發流量。
如下圖所示，server越多整個系統的處理能力就越強，在同一時刻能夠處理的請求越多。（前提是server後端依賴的服務也是可以橫向擴展來提高併發量的）
1.2 緩存
使用緩存來提高性能。 主要作用是提高單機處理能力。
比如，一臺服務器的邏輯是返回視頻的詳情信息，正常處理邏輯是，1解析請求中的視頻id，2通過視頻id向redis或mysql中獲取數據，3獲取數據之後再返回給客戶端。整個流程耗時最多的是第二步，因爲涉及到網絡的交互。
假設，整個請求耗時10ms，如果server是單進程單線程來處理請求，那麼每秒鐘可以處理100個請求。
那麼如果把第二步的時間縮短呢？考慮到視頻的信息變更不會很頻繁，同時熱門的視頻可能比較集中（尤其是放在首頁上方的焦點圖中推薦的視頻）。
可以將每次從redis或mysql訪問到的視頻的信息存放在本地的緩存中（獲取是分佈式緩存中），那麼下次再來一個請求的時候就可以直接從本地緩存中獲取（如果本地緩存沒有，再請求redis或mysql獲取數據），這樣在單個視頻請求併發量很大的情況下可以節省很多的時間）。
比如本地緩存超時時間是1秒，獲取本地緩存的耗時是1ms，那麼只有第一個請求耗時是10ms，剩下的請求都可以在1ms左右處理完，那麼每秒可以處理（1000ms-10ms）/ 1ms + 1 = 991個請求。 單機的qps是不是在請求比較熱門集中的情況下會提高很多嘛。
1.3 異步處理
當整個系統的處理能力有限，比如一個秒殺系統設計時每秒的併發量只能支持10000個。雖然系統可以支持橫向擴展，通過擴容來提高併發量。但是如果秒殺前的一秒鐘是無法預測到到底會有多大的併發請求量過來（只能根據歷年的請求量的增加比例等因素來預估請求量）。
所以，可以將所有的請求消息都先放入到消息隊列中（比如kafka），然後讓整個系統按照自己可以處理的併發量來從消息隊列中依次處理。 當然消息隊列的併發量要滿足，由於消息隊列不會處理複雜的邏輯，所以通過部署多個節點是可以達到很高的併發量。但是後臺系統就不是很容易，因爲系統很可能涉及到mysql的讀寫，事務等操作，併發量有時候提高會比較麻煩，如果一味的提高後臺系統的併發量最終可能會導致整個系統極其複雜。
