併發，在作業系統中，是指乙個時間段中有幾個程式都處於已啟動執行到執行完畢之間，且這幾個程式都是在同乙個處理機上執行，但任乙個時刻點上只有乙個程式在處理機上執行。
高併發(high concurrency)是使用技術手段使系統可以並行處理很多請求。
「併發」由於在網際網路架構中，已經從機器維度上公升到了系統架構層面，所以和「並行」已經沒有清晰的界限。「並」(同時)是其中的關鍵。由於「同時」會引發多久才叫同時的問題，將時間擴大，又根據不同業務關注點不同，引申出了引申指標。
算不算高併發，這個問題的答案需要加對比和前提。
對比包括：
-業界：在業界同類產品中併發量處於什麼位置。比如，美團外賣的日單量是千萬級別，乙個系統日單量在百萬，雖然差乙個數量級，但是相比大多數公司已經很不錯。
-自身：在自身系統中，併發問題是否已經是系統的瓶頸？如果是，這麼這個瓶頸怎麼打破？如果不是，那當初架構設計的時候是怎麼保證併發不是問題的？(別告訴我：是通過系統沒有訪問量來保證的[擦汗])。
前提包括：
-配置：用高配物理機得出的資料和最老最低配的虛擬器上的出來的結果是無法比較的。通常的配置有：cpu、記憶體、磁碟、頻寬、網絡卡
高併發的本質不是「多大算高併發」的乙個數字，而是從架構上、設計上、編碼上怎麼來保證或者解決由併發引起的問題。當別人問你：「做過高併發嗎？」回答者完全可以描述自己系統的各項指標，然後開始敘述自己對系統中對預防、解決併發問題作出的思考和行動。
怎麼處理高併發
處理高併發有六種方法 1 系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，這樣就可以抗高併發。2 快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家r...
怎麼實現高併發系統
脫離了業務的系統架構都是在紙上談兵，真正在複雜業務場景而且還高併發的時候，那系統架構一定不是那麼簡單的，用個 redis，用 mq 就能搞定？當然不是，真實的系統架構搭配上業務之後，會比這種簡單的所謂 高併發架構 要複雜很多倍。可以分為以下 6 點 將乙個系統拆分為多個子系統，用 dubbo 來搞。...
到底什麼級別才算是高併發？
寫這個話題是因為我對搜尋引擎給我的答案很不滿意，然後決定把思考的一些東西分享出來，希望可以大家彼此討論下。我們經常在面試的時候，被問到有沒有高併發的經驗？先不說哪些考高併發的裝逼公司。我思考的是什麼才算是高併發？你一天幾個pv肯定高不了。首先在網上查詢一下，並未找到明確的標準定義。那麼什麼是併發呢？...