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!
閱讀更多 程序員小樊 的文章