1.原因
由於系統都是連接數據庫的，但是一般最多數據庫每秒只能支撐幾千的並非，如果業務量激增，會導致系統宕機；因此需要從一下幾點入手設計
· 系統拆分
· 緩存
· MQ
· 分庫分表
· 讀寫分離
· 搜索
2.系統拆分
將一個系統進行功能拆分，如現在流行的微服務，每個服務連接的數據庫分開，分開部署。這樣可以將壓力進行拆分，緩解因為網絡和數據庫導致的高併發
3.緩存
大部分場景下，都是查詢多餘插入更新，也就是讀多寫少。因此設計時對常用的查詢內容必須進行緩存，查詢時先查緩存，再查數據庫；更新時也要更新緩存；
redis 單機支持幾萬的併發。項目設計時針對那些承載主要請求的讀場景，怎麼用緩存來抗高併發。
4.MQ
再考慮高併發寫的場景，比如一個業務操作要數據庫操作幾十次，增刪改增刪改，在普通環境下不會有問題，但是如果高併發絕對會出現問題；
如通訊分析項目，話單導入時多線程同時導入。如果多個用戶都同時導入，會有多個導入任務，幾十幾百甚至啟動上千的線程跑。也會導致系統出現問題；
可以將大量的寫請求灌入 MQ 裡，進行排隊，後邊系統慢慢寫，控制在數據庫承載範圍之內。MQ 單機支持幾萬併發，所以設計系統時，對應承載複雜寫業務邏輯的場景裡，如何用 MQ 來異步寫，提升併發性。
缺點：
· 系統可用性降低-外部依賴越多，越容易出現問題
· 系統複雜度提高-需要處理重複消費和丟失的問題
· 一致性問題-由於是異步需要保證數據的完整
Kafka、ActiveMQ、RabbitMQ、RocketMQ 優缺點
5.分庫分表
單個數據庫無法支持，可以考慮多個數據庫；如果單個表內容太多可以考慮把表分開存儲；單表數據量太大也可以表拆分或者類似分區表的形式處理，每個表的數據量保持少一點，提高 sql 跑的性能
6.讀寫分離
讀寫分離，就是大部分時候數據庫可能是讀多寫少，沒必要所有請求都集中在一個庫上，可以搞個主從架構，主庫寫入，從庫讀取，讀寫分離。讀流量太多的時候，還可以加更多的從庫
7.搜索
如Elasticsearch，簡稱 es。es 是分佈式的，可以隨便擴容，分佈式天然就可以支撐高併發，因為可以擴容加機器來扛更高的併發。一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜索類的操作，也可以用 es 來承載
8.項目設計的思考
在實際設計項目中，做高併發要遠比上面提到的點要複雜的多。需要考慮：
哪些需要分庫分表，哪些不需要分庫分表，單庫單表跟分庫分表如何 join，哪些數據要放到緩存裡去，放哪些數據才可以扛住高併發的請求
需要完成對一個複雜業務系統的分析之後，然後逐步逐步的加入高併發的系統架構的改造。
關注我不迷路，我是程序員小樊。歡迎點贊、收藏、評論+轉發，3Q！
閱讀更多 程序員小樊 的文章
