<bdo id='1ic85'></bdo><ul id='1ic85'></ul>
處理高并發的六種方法
1：系統拆分
將一個系統拆分為多個子系統，用dubbo來搞。然后每個系統連一個數據庫，這樣本來就一個庫，現在多個數據庫，這樣就可以抗高并發。
將一個系統進行功能拆分，如現在流行的微服務，每個服務連接的數據庫分開，分開部署。這樣可以將壓力進行拆分，緩解因為網絡和數據庫導致的高并發。
2：緩存
必須得用緩存。大部分的高并發場景，都是讀多寫少，那你完全可以在數據庫和緩存里都寫一份，然后讀的時候大量走緩存不就得了。畢竟人家redis輕輕松松單機幾萬的并發啊。沒問題的。所以你可以考慮慮考慮你的項目里，那些承載主要請求讀場景，怎么用緩存來抗高并發。
大部分場景下，都是查詢多余插入更新，也就是讀多寫少。因此設計時對常用的查詢內容必須進行緩存，查詢時先查緩存，再查數據庫；更新時也要更新緩存；
redis 單機支持幾萬的并發。項目設計時針對那些承載主要請求的讀場景，怎么用緩存來抗高并發。
3：MQ(消息隊列)
必須得用MQ。可能你還是會出現高并發寫的場景，比如說一個業務操作里要頻繁搞數據庫幾十次，增刪改增刪改，瘋了。那高并發絕對搞掛你的系統，人家是緩存你要是用redis來承載寫那肯定不行，數據隨時就被LRU(淘汰掉最不經常使用的)了，數據格式還無比簡單，沒有事務支持。所以該用mysql還得用mysql啊。那你咋辦？用MQ吧，大量的寫請求灌入MQ里，排隊慢慢玩兒，后邊系統消費后慢慢寫，控制在mysql承載范圍之內。所以你得考慮考慮你的項目里，那些承載復雜寫業務邏輯的場景里，如何用MQ來異步寫，提升并發性。MQ單機抗幾萬并發也是ok的。
再考慮高并發寫的場景，比如一個業務操作要數據庫操作幾十次，增刪改增刪改，在普通環境下不會有問題，但是如果高并發絕對會出現問題；
如通訊分析項目，話單導入時多線程同時導入。如果多個用戶都同時導入，會有多個導入任務，幾十幾百甚至啟動上千的線程跑。也會導致系統出現問題；
可以將大量的寫請求灌入 MQ 里，進行排隊，后邊系統慢慢寫，控制在數據庫承載范圍之內。MQ 單機支持幾萬并發，所以設計系統時，對應承載復雜寫業務邏輯的場景里，如何用 MQ 來異步寫，提升并發性。
缺點：
· 系統可用性降低-外部依賴越多，越容易出現問題
· 系統復雜度提高-需要處理重復消費和丟失的問題
· 一致性問題-由于是異步需要保證數據的完整
Kafka、ActiveMQ、RabbitMQ、RocketMQ 優缺點
4：分庫分表
可能到了最后數據庫層面還是免不了抗高并發的要求，好吧，那么就將一個數據庫拆分為多個庫，多個庫來抗更高的并發；然后將一個表拆分為多個表，每個表的數據量保持少一點，提高sql表的性能。
5：讀寫分離
這個就是說大部分時候數據庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
6：搜索
SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解決海量數據的 分布式全文檢索，因為搭建了集群，因此具備高可用的特性，同時對數據進行主從備份，避免了單點故障問題。可以做到數據的快速恢復。并且可以動態地添加新的節點，再對數據進行平衡,可以做到負載均衡：
如Elasticsearch，簡稱 es。es 是分布式的，可以隨便擴容，分布式天然就可以支撐高并發，因為可以擴容加機器來扛更高的并發。一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜索類的操作，也可以用 es 來承載
項目設計的思考
在實際設計項目中，做高并發要遠比上面提到的點要復雜的多。需要考慮：
哪些需要分庫分表，哪些不需要分庫分表，單庫單表跟分庫分表如何 join，哪些數據要放到緩存里去，放哪些數據才可以扛住高并發的請求
需要完成對一個復雜業務系統的分析之后，然后逐步逐步的加入高并發的系統架構的改造
