處理高併發的一般思路

前言

今天看見有人聊目前系統有2億的PV，該如何優化？當我看到這個話題的時候，突然在想自己工作中也遇到了不少高併發的場景了，所以即興發揮，在這裏簡單總結和分享下，歡迎指正和補充。

正文

讀操作

關於讀，我們一般遵循如下優先級：

優先級	技術方案	說明	示例
最高	儘可能靜態化	對實時性要去不高的數據，儘可能全走CDN	例如獲取基礎商品信息
高	就近使用內存	優先級服務器內存、遠程內存服務	例如秒殺、搶購庫存(優先分配庫存到服務器內存，其次遠程內存服務<又涉及額外網絡IO>)
極低	數據庫(能不讀就不要讀)	連接池、sql優化	常見業務

寫操作

關於寫，我們一般會按照數據的一致性要求級別來看：

數據一致性要求	技術方案
不高	先寫內存(優先級從服務器內存到遠程內存服務) 再異步儲存
高	同步完成最關鍵的任務 異步保證其他任務最終成功

削峯限流

從簡單到複雜:

簡單程度	技術方案
最簡單	百分比流量拒絕(隨機、沒有先到先得不夠公平)
簡單	原子操作限流(優先級使用服務器內存、其次遠程內存服務)
稍麻煩	隊列限流(先到先得，公平)

服務穩定性

在高併發的場景，有時候爲了保證核心業務的正常進行，我們需要對一些次要的業務進行服務降級。簡單的降級方案如下：

1. 配置開關降級：手動進行配置開關降級
2. 定時開關降級：自動定時降級

系統架構

關於系統架構，不用想的太複雜，簡單的拆離此業務即可。

運維架構

部署層面，儘可能的把此類服務單獨部署。

武器

"工欲善其事，必先利其器"，處理高併發我們當然少不了好的武器。以下是高併發“三劍客”：

技術名詞	說明
異步	異步回調，層層回調似災難(Promise也是很臃腫的鏈式代碼)
epoll	IO多路複用，nginx/redis方案
協程	輕量，用戶態調度高併發能力