前言
今天看見有人聊目前系統有2億的PV，該如何優化？當我看到這個話題的時候，突然在想自己工作中也遇到了不少高併發的場景了，所以即興發揮，在這裡簡單總結和分享下，歡迎指正和補充。
正文
讀操作
關於讀，我們一般遵循如下優先順序：
| 優先順序 | 技術方案 | 說明 | 示例 |
|---|---|---|---|
| 最高 | 儘可能靜態化 | 對實時性要去不高的資料，儘可能全走CDN | 例如獲取基礎商品資訊 |
| 高 | 就近使用記憶體 | 優先順序伺服器記憶體、遠端記憶體服務 | 例如秒殺、搶購庫存(優先分配庫存到伺服器記憶體，其次遠端記憶體服務<又涉及額外網路IO>) |
| 極低 | 資料庫(能不讀就不要讀) | 連線池、sql優化 | 常見業務 |
寫操作
關於寫，我們一般會按照資料的一致性要求級別來看：
| 資料一致性要求 | 技術方案 |
|---|---|
| 不高 | 先寫記憶體(優先順序從伺服器記憶體到遠端記憶體服務) 再非同步儲存 |
| 高 | 同步完成最關鍵的任務 非同步保證其他任務最終成功 |
削峰限流
從簡單到複雜:
| 簡單程度 | 技術方案 |
|---|---|
| 最簡單 | 百分比流量拒絕(隨機、沒有先到先得不夠公平) |
| 簡單 | 原子操作限流(優先順序使用伺服器記憶體、其次遠端記憶體服務) |
| 稍麻煩 | 佇列限流(先到先得，公平) |
服務穩定性
在高併發的場景，有時候為了保證核心業務的正常進行，我們需要對一些次要的業務進行服務降級。簡單的降級方案如下：
- 配置開關降級：手動進行配置開關降級
- 定時開關降級：自動定時降級
系統架構
關於系統架構，不用想的太複雜，簡單的拆離此業務即可。
運維架構
部署層面，儘可能的把此類服務單獨部署。
武器
"工欲善其事，必先利其器"，處理高併發我們當然少不了好的武器。以下是高併發“三劍客”：
| 技術名詞 | 說明 |
|---|---|
| 非同步 | 非同步回撥，層層回撥似災難(Promise也是很臃腫的鏈式程式碼) |
| epoll | IO多路複用，nginx/redis方案 |
| 協程 | 輕量，使用者態排程高併發能力 |