高并發（High Concurrency）是一種系統運行過程中遇到的一種“短時間內遇到大量操作請求”的情況，主要發生在web系統集中大量訪問收到大量請求（例如：12306的搶票情況；天貓雙十一活動）。該情況的發生會導致系統在這段時間內執行大量操作，例如對資源的請求，數據庫的操作等。高并發（High Concurrency）是互聯網分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時并行處理很多請求。我們所說的高并發指兩方面，第一個方面指的是同一時刻有大量的請求訪問系統 第二個方面指的是有大量的請求在一個時間段內訪問系統，一般時間段有個指標，是一秒內能處理的請求數量。
高并發相關常用的一些指標有:
1.響應時間（Response Time）：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。
2.吞吐量（Throughput）：單位時間內處理的請求數量。
3.每秒查詢率QPS（Query Per Second）：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這么明顯。
4.并發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統，同時在線量一定程度上代表了系統的并發用戶數。
"高并發和多線程”總是被一起提起，給人感覺兩者好像相等，實則高并發 ≠ 多線程
1.多線程
多線程是java的特性，因為現在cpu都是多核多線程的，可以同時執行幾個任務，為了提高jvm的執行效率，java提供了這種多線程的機制，以增強數據處理效率。多線程對應的是cpu，高并發對應的是訪問請求，可以用單線程處理所有訪問請求，也可以用多線程同時處理訪問請求。
在過去單CPU時代，單任務在一個時間點只能執行單一程序。之后發展到多任務階段，計算機能在同一時間點并行執行多任務或多進程。雖然并不是真正意義上的“同一時間點”，而是多個任務或進程共享一個CPU，并交由操作系統來完成多任務間對CPU的運行切換，以使得每個任務都有機會獲得一定的時間片運行。
再后來發展到多線程技術，使得在一個程序內部能擁有多個線程并行執行。一個線程的執行可以被認為是一個CPU在執行該程序。當一個程序運行在多線程下，就好像有多個CPU在同時執行該程序。
總之，多線程即可以這么理解：多線程是處理高并發的一種編程方法，即并發需要用多線程實現。
2.高并發
高并發不是JAVA的專有的東西，是語言無關的廣義的，為提供更好互聯網服務而提出的概念。
典型的場景，例如：12306搶火車票，天貓雙十一秒殺活動等。該情況的發生會導致系統在這段時間內執行大量操作，例如對資源的請求，數據庫的操作等。如果高并發處理不好，不僅僅降低了用戶的體驗度（請求響應時間過長），同時可能導致系統宕機，嚴重的甚至導致OOM異常，系統停止工作等。
如果要想系統能夠適應高并發狀態，則需要從各個方面進行系統優化，包括，硬件、網絡、系統架構、開發語言的選取、數據結構的運用、算法優化、數據庫優化等……而多線程只是其中解決方法之一。
互聯網分布式架構設計，提高系統并發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。
垂直擴展：提升單機處理能力。垂直擴展的方式又有兩種：
(1)增強單機硬件性能，例如：增加CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬盤如SSD，擴充硬盤容量如2T，擴充系統內存如128G；
(2)提升單機架構性能，例如：使用Cache來減少IO次數，使用異步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間；
水平擴展：只要增加服務器數量，就能線性擴充系統性能。
總結：在互聯網業務發展非常迅猛的早期，如果預算不是問題，強烈建議使用“增強單機硬件性能”的方式提升系統并發能力，因為這個階段，公司的戰略往往是發展業務搶時間，而“增強單機硬件性能”往往是最快的方法。不管是提升單機硬件性能，還是提升單機架構性能，都有一個致命的不足：單機性能總是有極限的。所以互聯網分布式架構設計高并發終極解決方案還是水平擴展。
從宏觀角度看，高并發系統設計的目標有三個：高性能、高可用，以及高可擴展。這3個目標是需要通盤考慮的，因為它們互相關聯、甚至也會相互影響。
1.高性能：性能體現了系統的并行處理能力，在有限的硬件投入下，提高性能意味著節省成本。同時，性能也反映了用戶體驗，響應時間分別是100毫秒和1秒,給用戶的感受是完全不同的。
2.高可用：表示系統可以正常服務的時間。一個全年不停機、無故障；另一個隔三差五出線上事故、宕機，用戶肯定選擇前者。另外，如果系統只能做到90%可用，也會大大拖累業務。
3.高擴展：表示系統的擴展能力，流量高峰時能否在短時間內完成擴容，更平穩地承接峰值流量，比如雙11活動、明星離婚等熱點事件。
1.平均響應時間：最常用，但是缺陷很明顯，對于慢請求不敏感。比如1萬次請求，其中9900次是1ms，100次是100ms，則平均響應時間為1.99ms，雖然平均耗時僅增加了0.99ms，但是1%請求的響應時間已經增加了100倍。
2.TP90、TP99等分位值：將響應時間按照從小到大排序，TP90表示排在第90分位的響應時間， 分位值越大，對慢請求越敏感。
3.吞吐量：和響應時間呈反比，比如響應時間是1ms，則吞吐量為每秒1000次。
高可用性是指系統具有較高的無故障運行能力，可用性 = 正常運行時間 / 系統總運行時間，一般使用幾個9來描述系統的可用性。對于高并發系統來說，最基本的要求是：保證3個9或者4個9。原因很簡單，如果你只能做到2個9，意味著有1%的故障時間，像一些大公司每年動輒千億以上的GMV或者收入，1%就是10億級別的業務影響。
面對突發流量，不可能臨時改造架構，最快的方式就是增加機器來線性提高系統的處理能力。對于業務集群或者基礎組件來說，擴展性 = 性能提升比例 / 機器增加比例，理想的擴展能力是：資源增加幾倍，性能提升幾倍。通常來說，擴展能力要維持在70%以上。但是從高并發系統的整體架構角度來看，擴展的目標不僅僅是把服務設計成無狀態就行了，因為當流量增加10倍，業務服務可以快速擴容10倍，但是數據庫可能就成為了新的瓶頸。像MySQL這種有狀態的存儲服務通常是擴展的技術難點，如果架構上沒提前做好規劃（垂直和水平拆分），就會涉及到大量數據的遷移。因此，高擴展性需要考慮：服務集群、數據庫、緩存和消息隊列等中間件、負載均衡、帶寬、依賴的第三方等，當并發達到某一個量級后，上述每個因素都可能成為擴展的瓶頸點。
1.分布式緩存：redis、memcached等，結合CDN來解決圖片文件等訪問。
2.消息隊列中間件：activeMQ等，解決大量消息的異步處理能力。
3.應用拆分:一個工程被拆分為多個工程部署，利用dubbo解決多工程之間的通信。
4.數據庫垂直拆分和水平拆分(分庫分表)等。
5.數據庫讀寫分離，解決大數據的查詢問題。
6.還可以利用nosql ，例如mongoDB配合mysql組合使用。
7.還需要建立大數據訪問情況下的服務降級以及限流機制等。
官方微信
官方抖音
京公網安備 11030102010736號