[[396453]]

一、為啥會有高并發

現在用互聯網的人越來越多，很多app、網站、系統承載的都是高并發請求，可能高峰期每秒并發量幾千，很正常的。尤其是電商App，如果是雙十一之類的，每秒并發幾萬幾十萬都有可能，高并發訪問帶來的問題是系統和數據庫扛不住，容易宕機，要知道數據庫支撐到每秒并發兩三千的時候，基本就快完了，數據庫如果瞬間承載每秒5000,8000，甚至上萬的并發，一定會宕機，比如mysql就壓根兒扛不住這么高的并發量。

那么如此之高的并發量，加上原本就如此之復雜的業務，我們該如何設計一個可以支持高并發訪問的系統呢，主要從以下幾點去考慮：

• 系統拆分
• 使用緩存
• 引入MQ
• 分庫分表
• 讀寫分離

二、設計高并發系統的關鍵點

2.1、系統拆分

將一個大的系統拆分為基于微服務架構的多個子系統，技術落地選擇使用SpringCloud來做，然后每個子系統連一個數據庫，這樣本來就一個庫，現在多個數據庫，這樣也可以扛高并發。

2.2、使用緩存

緩存，一定要用緩存。大部分的高并發場景，都是讀多寫少，我們完全可以在數據庫和緩存里都寫一份，然后讀的時候大量走緩存，可以引入Redis作為分布式緩存的技術解決方案，redis單機就支持每秒幾萬的并發，在集群情況下更是可以達到每秒幾十萬的并發。所以我們要考慮項目里那些承載主要請求的讀場景，怎么用緩存來抗高并發，同時也得處理好【緩存雪崩】、【緩存穿透】、【緩存擊穿】這些問題

2.3、引入MQ

MQ，一定得用上MQ。因為系統還是會出現高并發寫的場景，比如說一個業務操作里要頻繁搞數據庫幾十次，增刪改增刪改，那高并發訪問的情況下絕對搞掛數據庫，這個時候就可以考慮用MQ去削峰，將大量的寫請求先灌入MQ里，排隊慢慢玩兒，后邊系統消費后慢慢寫，控制在數據庫承載范圍之內。所以我們要考慮項目里那些承載復雜寫業務邏輯的場景里，如何用MQ來異步寫，提升并發性。MQ單機可以扛得起幾萬并發。MQ的技術選型可以選擇用rabbitMq或者Kafka。當然了，系統引入MQ之后，也會導致整個系統的可用性降低，系統復雜度提高，系統引入的外部依賴越多，越容易掛掉。所以引入MQ后，要考慮【如何保證消息隊列的高可用】、【如何保證消息沒有重復消費】、【如何處理消息丟失的情況】、【如何保證消息傳遞的順序性】等問題，引入MQ有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉。

2.4、分庫分表

分庫分表，可能到了最后數據庫層面還是免不了抗高并發的要求，那么就將一個數據庫拆分為多個庫，多個庫來扛更高的并發;然后將一個表拆分為多個表，每個表的數據量保持在一定范圍內，提高sql跑的性能。推薦使用ShardingSphere作為分庫分表的技術解決方案

2.5、讀寫分離

讀寫分離，這個就是說大部分時候數據庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。