處理高併發的通常思路

前言

今天看見有人聊目前系統有2億的PV，該如何優化？當我看到這個話題的時候，忽然在想本身工做中也遇到了很多高併發的場景了，因此即興發揮，在這裏簡單總結和分享下，歡迎指正和補充。

正文

讀操做

關於讀，咱們通常遵循以下優先級：

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

寫操做

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

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

削峯限流

從簡單到複雜:

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

服務穩定性

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

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

系統架構

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

運維架構

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

武器

"工欲善其事，必先利其器"，處理高併發咱們固然少不了好的武器。如下是高併發「三劍客」：

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