處理高併發有六種方法
1：系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，這樣就可以抗高併發。
2：快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發啊。沒問題的。所以你可以考的慮考慮你的專案裡，那些承載主要請求讀場景，怎麼用快取來抗高併發。
3：mq(訊息佇列)，必須得用mq。可能你還是會出現高併發寫的場景，比如說乙個業務操作裡要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。那高併發絕對搞掛你的系統，人家是快取你要是用redis來承載寫那肯定不行，資料隨時就被lru(淘汰掉最不經常使用的)了，資料格式還無比簡單，沒有事務支援。所以該用mysql還得用mysql啊。那你咋辦？用mq吧，大量的寫請求灌入mq裡，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在mysql承載範圍之內。所以你得考慮考慮你的專案裡，那些承載複雜寫業務邏輯的場景裡，如何用mq來非同步寫，提公升併發性。mq單機抗幾萬併發也是ok的。
4：分庫分表，可能到了最後資料庫層面還是免不了抗高併發的要求，好吧，那麼就將乙個資料庫拆分為多個庫，多個庫來抗更高的併發；然後將乙個表拆分為多個表，每個表的資料量保持少一點，提高sql跑的效能。
6：solrcloud:
solrcloud(solr 雲)是solr提供的分布式搜尋方案，可以解決海量資料的 分布式全文檢索，因為搭建了集群，因此具備高可用的特性，同時對資料進行主從備份，避免了單點故障問題。可以做到資料的快速恢復。並且可以動態的新增新的節點，再對資料進行平衡,可以做到負載均衡：
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...
高併發處理
真實的支撐複雜業務場景的高併發系統架構其實是非常複雜的。比如說每秒百萬併發的中介軟體系統 每日百億請求的閘道器系統 瞬時每秒幾十萬請求的秒殺大促系統 支撐幾億使用者的大規模高並發電商平台架構，等等。為了支撐高併發請求，在系統架構的設計時，會結合具體的業務場景和特點，設計出各種複雜的架構，這需要大量底...
高併發處理
1.垂直分層 dns層，跨機房部署，負載均衡，共享儲存實現動靜分離，nginx後掛載伺服器集群，伺服器集群後面掛載微服務化，微服務後掛載資料庫讀寫分離 分庫分表 訊息佇列 任務佇列 任務排程 資料庫同意歸檔 非同步批處理 2.水平分層 根據業務劃分業務線，每個業務設計區分鍵，根據userno實現使用...