高并發設計，都有哪些技術方案？
大家好，我是 Tom哥。
作為互聯網從業者，高并發一直是我們繞不開的一個話題。
那么高并發系統都有哪些經驗，掌握核心技巧，你可以快速成為一個架構師，主導一些高訪問量系統的架構設計。
然后，升職加薪自然也就是水到渠成的事。
一、負載均衡
靠優化單臺機器的內存、CPU、磁盤、網絡帶寬，使其發揮極致性能，已經不太現實。
正所謂 "雙拳難敵四手，惡虎還怕群狼"，現在早已經是分布式時代，靠的是shu量取勝，也稱之為水平伸縮方案。
這么多的系統，如何流量調度，這里的第一道入口就是負載均衡。
負載均衡，它的職責是將網絡請求 “均攤”到不同的機器上。避免集群中部分服務器壓力過大，而另一些服務器比較空閑的情況。
通過負載均衡，可以讓每臺服務器獲取到適合自己處理能力的負載。在為高負載服務器分流的同時，還可以避免資源浪費，一舉兩得。
常見的負載算法：
- 隨機算法。
- 輪詢算法。
- 輪詢權重算法。
- 一致性哈希算法。
- 最小連接。
- 自適應算法。
常用負載均衡工具：
- LVS。
- Nginx。
- HAProxy。
對于一些大型系統，一般會采用 DNS+四層負載+七層負載的方式進行多層次負載均衡。
二、分布式微服務
過去是一個大而全的系統，面對復雜的業務規則，我們采用分而治之的思想，通過SOA架構，將一個大的系統拆分成若干個微服務，粒度越來越小，稱之為微服務架構。
每個微服務獨立部署，服務和服務間采用輕量級的通信機制，如：標準的HTTP協議、或者私有的RPC協議。
微服務特點：
- 按照業務劃分服務，單個服務代碼量小，業務單一，容易維護。
- 每個微服務都有自己獨立的基礎組件，例如數據庫。
- 微服務之間的通信是通過HTTP協議或者私有協議，且具有容錯能力。
- 微服務有一套服務治理的解決方案，服務之間不耦合，可以隨時加入和剔除。
- 單個微服務能夠集群化部署，有負載均衡的能力。
- 整個微服務系統應該有完整的安全機制，包括用戶驗證，權限驗證，資源保護。
- 整個微服務系統有鏈路追蹤的能力。
- 有一套完整的實時日志系統。
市面常用微服務框架有：Spring Cloud 、Dubbo 、kubernetes、gRPC、Thrift 等。
這么多的微系統之間如何感知?這里面會引入注冊中心。
常用的注冊中心有：Zookeeper、etcd、Eureka、Nacos、Consul。
萬事有利就有弊，分布式微服務由于拆分的過細，引入一些復雜化問題需要關注：
- 分布式事務。
- 限流機制。
- 熔斷機制。
- 網關。
- 服務鏈路追蹤。
三、緩存機制
性能不夠，緩存來湊。要想快速提升性能，緩存肯定少不了。
緩存能夠帶來性能的大幅提升，以 Memcache 為例，單臺 Memcache 服務器簡單的 key-value 查詢能夠達到 TPS 50000 以上;Redis性能數據是10W+ QPS。
為什么緩存的速度那么快?
從上圖中發現，同機房兩臺服務器跑個來回，再從內存中順序讀取1M數據，共耗時0.75ms。如果從硬盤讀取，做一次磁盤尋址需要10ms，再從磁盤里順序讀取1M數據需要30ms。可見，使用內存緩存性能上提高多個數量級，同時也能支持更高的并發量。
常見的緩存分為本地緩存和分布式緩存，區別在與是否要走網絡通訊。
本地緩存是部署在應用服務器中，而我們應用服務器通常會部署多臺，當數據更新時，我們不能確定哪臺服務器本地中了緩存，更新或者刪除所有服務器的緩存不是一個好的選擇，所以我們通常會等待緩存過期。因此，這種緩存的有效期很短，通常為分鐘或者秒級別，以避免返回前端臟數據。
相反，分布式緩存采用集群化管理，支持水平擴容，并提供客戶端路由數據，數據一致性維護更好。雖然有不到 1ms 的網絡開銷，但比起其優勢，這點損耗微不足道。
緩存更新常用策略?
- Cache aside，通常會先更新數據庫，然后再刪除緩存，為了兜底還會設置緩存時間。
- Read/Write through， 一般是由一個 Cache Provider 對外提供讀寫操作，應用程序不用感知操作的是緩存還是數據庫。
- Write behind，延遲寫入，Cache Provider 每隔一段時間會批量寫入數據庫，大大提升寫的效率。像操作系統的page cache也是類似機制。
四、分布式關系型數據庫
MySQL數據庫采用B+數索引，三層結構，為了保證IO性能，一般建議單表存儲 千萬 條數據。
如果遇到單機數據庫性能瓶頸，我們可以考慮分表。
分表又可以細分為 垂直分表 和 水平分表 兩種形式。
1、垂直分表
數據表垂直拆分就是縱向地把一張表中的列拆分到多個表，表由“寬”變“窄”，簡單來講，就是將大表拆成多張小表，一般會遵循以下幾個原則：
- 冷熱分離，把常用的列放在一個表，不常用的放在一個表。
- 字段更新、查詢頻次拆分。
- 大字段列獨立存放。
- 關系緊密的列放在一起。
2、水平分表
表結構維持不變，對數據行進行切分，將表中的某些行切分到一張表中，而另外的某些行又切分到其他的表中，也就是說拆分后數據集的并集等于拆分前的數據集。
分庫分表技術點：
- SQl組合。因為是邏輯表名，需要按分表鍵計算對應的物理表編號，根據邏輯重新組裝動態的SQL。
- 數據庫路由。如果采用分庫，需要根據邏輯的分表編號計算數據庫的編號。
- 結果合并。如果查詢沒有傳入指定的分表鍵，會全庫執行，此時需要將結果合并再輸出。
目前市面有很多的開源框架，大致分為兩種模式：
Proxy模式。SQL 組合、數據庫路由、執行結果合并等功能全部存放在一個代理服務中，業務方可以當做。
- 優點：支持多種語言。升級方便。對業務代碼無侵入。
- 缺點：額外引入一個中間件，容易形成流量瓶頸，安全風險較高，有運維成本。
Client 模式。常見是 sharding-jdbc，業務端系統只需要引入一個jar包即可，按照規范配置路由規則。jar 中處理 SQL 組合、數據庫路由、執行結果合并等相關功能。
- 優點：簡單、輕便。不存在流量瓶頸，減少運維成本
- 缺點：單語言，升級不方便。
實現思路：
1、如何選擇分表鍵。
數據盡量均勻分布在不同表或庫、跨庫查詢操作盡可能少、這個字段的值不會變。比如電商訂單采用user_id。
2、分片策略。
根據范圍分片、根據 hash 值分片、根據 hash 值及范圍混合分片
3、如何編寫業務代碼。結合具體的業務實現。
4、歷史數據遷移。
- 增量數據監聽 binlog，然后通過 canal 通知遷移程序開始增量數據遷移。
- 開啟任務，全量數據遷移。
- 開啟雙寫，并關閉增量遷移任務。
- 讀業務切換到新庫。
- 線上運行一段時間，確認沒有問題后，下線老庫的寫操作。
有一種說法：數據量大，就分表;并發高，就分庫。
在實際的業務開發中，要做好數據量的增長預測，做好技術方案選型。另外，在引入分表方案后，要考慮數據傾斜問題，這個跟分表鍵有很大關系，避免數據分布不均衡影響系統性能。
五、分布式消息隊列
并不是所有的調用都要走同步形式，對于時間要求不高、或者非核心邏輯，我們可以采用異步處理機制。
也就衍生出消息隊列。
消息隊列主要有三種角色：生產者、消息隊列、消費者。
生產端核心的邏輯處理完后，會封裝一個MQ消息，發送到消息隊列。下游系統，如果關心這個事件，只需要訂閱這個 topic ，便可以收到消息，進行后續的業務邏輯處理。
兩者之間通過消息中間件完成了解耦，系統的擴展性非常高。
常用的消息框架有哪些?
ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaQ，RocketMQ、Pulsar 等。
消息隊列的應用場景?
- 異步處理。將一個請求鏈路中的非核心流程，拆分出來，異步處理，減少主流程鏈路的處理邏輯，縮短RT，提升吞吐量。如：注冊新用戶發短信通知。
- 削峰填谷。避免流量暴漲，打垮下游系統，前面會加個消息隊列，平滑流量沖擊。比如：秒殺活動。生活中像電源適配器也是這個原理。
- 應用解耦。兩個應用，通過消息系統間接建立關系，避免一個系統宕機后對另一個系統的影響，提升系統的可用性。如：下單異步扣減庫存。
- 消息通訊。內置了高效的通信機制，可用于消息通訊。如：點對點消息隊列、聊天室。
六、CDN
CDN 全稱 (Content Delivery Network)，內容分發網絡。
目的是在現有的網絡中增加一層網絡架構，將網站的內容發布到最接近用戶的網絡“邊緣”，使用戶可以就近取得所需的內容，提高用戶訪問網站的響應速度。
CDN = 鏡像(Mirror)+緩存(Cache)+整體負載均衡(GSLB)。
CDN都以緩存網站中的靜態數據為主，如：CSS、JS、圖片和靜態頁面等數據。用戶從主站服務器中請求到動態內容后，再從CDN下載靜態數據，從而加速網頁數據內容的下載速度。
主要特點：
- 本地Cache加速。
- 鏡像服務。
- 遠程加速。
- 帶寬優化。
- 集群抗攻擊。
應用場景
- 網站站點/應用加速。
- 視音頻點播/大文件下載分發加速。
- 視頻直播加速。
- 移動應用加速。
七、其他
作為補充，像分布式文件系統、大數據、NoSQL、NewSQL，慢慢也開始成為高并發系統的周圍框架生態補充。
