脫離了業務的系統架構都是在紙上談兵，真正在複雜業務場景而且還高併發的時候，那系統架構一定不是那麼簡單的，用個 redis，用 mq 就能搞定？當然不是，真實的系統架構搭配上業務之後，會比這種簡單的所謂「高併發架構」要複雜很多倍。
可以分為以下 6 點：
將乙個系統拆分為多個子系統，用 dubbo 來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以扛高併發麼。
快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家 redis 輕輕鬆鬆單機幾萬的併發。所以你可以考慮考慮你的專案裡，那些承載主要請求的讀場景，怎麼用快取來抗高併發。
mq，必須得用 mq。可能你還是會出現高併發寫的場景，比如說乙個業務操作裡要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。那高併發絕對搞掛你的系統，你要是用 redis 來承載寫那肯定不行，人家是快取，資料隨時就被 lru 了，資料格式還無比簡單，沒有事務支援。所以該用 mysql 還得用 mysql 啊。那你咋辦？用 mq 吧，大量的寫請求灌入 mq 裡，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在 mysql 承載範圍之內。所以你得考慮考慮你的專案裡，那些承載複雜寫業務邏輯的場景裡，如何用 mq 來非同步寫，提公升併發性。mq 單機抗幾萬併發也是 ok 的，這個之前還特意說過。
分庫分表，可能到了最後資料庫層面還是免不了抗高併發的要求，好吧，那麼就將乙個資料庫拆分為多個庫，多個庫來扛更高的併發；然後將乙個表拆分為多個表，每個表的資料量保持少一點，提高 sql 跑的效能。
讀寫分離，這個就是說大部分時候資料庫可能也是讀多寫少，沒必要所有請求都集中在乙個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞乙個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
elasticsearch，簡稱 es。es 是分布式的，可以隨便擴容，分布式天然就可以支撐高併發，因為動不動就可以擴容加機器來扛更高的併發。那麼一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜尋類的操作，也可以考慮用 es 來承載。
怎麼處理高併發
處理高併發有六種方法 1 系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，這樣就可以抗高併發。2 快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家r...
高併發到底要怎麼算才是高併發
併發，在作業系統中，是指乙個時間段中有幾個程式都處於已啟動執行到執行完畢之間，且這幾個程式都是在同乙個處理機上執行，但任乙個時刻點上只有乙個程式在處理機上執行。高併發 high concurrency 是使用技術手段使系統可以並行處理很多請求。併發 由於在網際網路架構中，已經從機器維度上公升到了系統...
高併發系統設計
高併發系統主要是為了解決在有限的資源下解決最核心的問題，並發現以後可能會出現的問題。高併發原則一般遵守如下幾個設計原則 1.無狀態 指的是應用在處理業務邏輯期間盡量減少鎖的使用 降低網路通訊延遲 無資料持久化操作等，以此來增加應用系統的效能。2.拆分 大而全的系統，可根據實際的訪問量來拆分系統，來實...