一,高併發的理解html
1.概念:就是短期內遇到大量操做請求,致使站點服務器/db服務器資源被佔滿甚至嚴重時直接致使宕java
2.影響:沒有作高併發預處理的系統會給用戶不好的體驗感;mysql
3.系統好壞的衡量:衡量一個系統的好壞,除了業務外,還有就是系統的吞吐量(單位時間內處理的請求數)-----QPS(每秒鐘能處理的請求數)和響應時間redis
二,區分一下高併發和多線程的關係----曾經我也是單純的理解高併發就是多線程,錯的很離譜算法
1.多線程的理解:sql
多線程是java的特性,由於如今cpu都是多核多線程的,能夠同時執行幾個任務,爲了提升jvm的執行效率,java提供了這種多線程的機制,以加強數據處理效率。數據庫
多線程對應的是cpu,高併發對應的是訪問請求,能夠用單線程處理全部訪問請求,也能夠用多線程同時處理訪問請求。編程
在過去單CPU時代,單任務在一個時間點只能執行單一程序。以後發展到多任務階段,計算機能在同一時間點並行執行多任務或多進程。雖然並非真正意義上的「同一時間點」,而是多個任務或進程共享一個CPU,並交由操做系統來完成多任務間對CPU的運行切換,以使得每一個任務都有機會得到必定的時間片運行。緩存
再後來發展到多線程技術,使得在一個程序內部能擁有多個線程並行執行。一個線程的執行能夠被認爲是一個CPU在執行該程序。當一個程序運行在多線程下,就好像有多個CPU在同時執行該程序服務器
2.多線程和高併發的關係
要想系統可以適應高併發狀態,則須要從各個方面進行系統優化,包括,硬件、網絡、系統架構、開發語言的選取、數據結構的運用、算法優化、數據庫優化等…而多線程只是其中解決方法之一。
3.併發編程的幾個要素
4.使用多線程技術編程須要注意的幾個點
4.1 清楚一個線程的五個狀態
4.2 理解悲觀鎖和樂觀鎖
4.3懂線程之間的協做(wait/sleep/notify等)
4.4 知道何時使用線程池
5.高併發的場景
通常像火車票搶票,秒殺 系統,雙11或者京東618活動等這種太明顯不過了,這種仍是正常的業務範圍,蠻好理解的,還有一種就是惡意的攻擊,致使系統的某個功能近乎癱瘓,好比驗證碼的請求等,
假設系統的一些架構方便的併發措施都作到位了,例如,重要系統配備了好的資源(高質量服務器),同時使用集羣方式提供服務,增長了redis集羣配置等,最後須要處理的就是底層數據庫那塊了,
否則前面那麼多請求都吃下來了,到了底層掉鏈子跟不上那也不行:
在此,我的理解爲併發無非就是併發讀和併發寫,併發讀還好,通常使用緩存就能夠搞定,併發寫技術就比較多了;
通常咱們都知道 併發時最怕的就是對共享變量的同時訪問致使髒數據的產生,因此通常會加鎖:對象鎖(例如:syncrinized等關鍵字)和 分佈式鎖(數據庫鎖,redis,zookeeper)
對象鎖顧名思義就是鎖住當前對象--只能用在單服務器上,對於分佈式系統或者單系統分佈式部署時對共享資源的訪問就必須使用分佈式鎖了,此時對象鎖無法用了
像秒殺系統可使用緩存讓還有數量時均可以看到,而在開搶後得看我的運氣了(網絡等緣由),此時使用樂觀鎖(共享鎖)就搞定了嘛
像銀行的消費後更新銀行卡餘額,使用悲觀鎖(排斥鎖)就能夠
具體想搞清楚分佈式鎖的請看下面這個連接:https://www.cnblogs.com/toutou/archive/2018/09/24/9554974.html
6.高併發的技術解決方案
a.分佈式緩存:redis、memcached等,
b.系統採用水平方向擴展,儘可能使用集羣來分散處理多請求。
c.應用拆分:一個工程被拆分爲多個工程部署,利用dubbo解決多工程之間的通訊。
d.數據庫分庫分表等。
e .數據庫讀寫分離,解決大數據的查詢問題。
f.還能夠利用nosql ,例如mongoDB配合mysql組合使用。
g.還須要創建大數據訪問狀況下的服務降級以及限流機制等。
h.消息隊列中間件:activeMQ等,解決大量消息的異步處理能力。
.............