在高併發的情景下進行系統設計，
可以分為以下 6 點：
快取mq
分庫分表
讀寫分離
elasticsearch
將乙個系統拆分為多個子系統，用 rpc 來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以扛高併發麼。
大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟 redis 輕輕鬆鬆單機幾萬的併發。所以你可以考慮考慮你的專案裡，那些承載主要請求的讀場景，怎麼用快取來抗高併發。
可能你還是會出現高併發寫的場景，比如說乙個業務操作裡要頻繁搞資料庫幾十次，增刪改增刪改。那高併發絕對搞掛你的系統，你要是用 redis 來承載寫那肯定不行，人家是快取，資料隨時就被 lru 了，資料格式還無比簡單，沒有事務支援。所以該用 mysql 還得用 mysql 啊。那你咋辦？用 mq 吧，大量的寫請求灌入 mq 裡，後邊系統消費後慢慢寫，控制在 mysql 承載範圍之內。所以你得考慮考慮你的專案裡，那些承載複雜寫業務邏輯的場景裡，如何用 mq 來非同步寫，提公升併發性。
分庫分表，可能到了最後資料庫層面還是免不了抗高併發的要求，好吧，那麼就將乙個資料庫拆分為多個庫，多個庫來扛更高的併發；然後將乙個表拆分為多個表，每個表的資料量保持少一點，提高 sql 跑的效能。
讀寫分離，這個就是說大部分時候資料庫可能也是讀多寫少，沒必要所有請求都集中在乙個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞乙個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
es 是分布式的，可以隨便擴容，分布式天然就可以支撐高併發，因為動不動就可以擴容加機器來扛更高的併發。那麼一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜尋類的操作，也可以考慮用 es 來承載。
高併發系統設計
高併發系統主要是為了解決在有限的資源下解決最核心的問題，並發現以後可能會出現的問題。高併發原則一般遵守如下幾個設計原則 1.無狀態 指的是應用在處理業務邏輯期間盡量減少鎖的使用 降低網路通訊延遲 無資料持久化操作等，以此來增加應用系統的效能。2.拆分 大而全的系統，可根據實際的訪問量來拆分系統，來實...
高併發系統設計 限流
前面學習過的熔斷和降級都是通過暫時關閉某些非核心服務或者元件來保護核心系統的可用性。但是並不是所有的場景下都可以使用熔斷降級的策略，例如當核心服務產生比較大的影響時，總不能把核心服務進行熔斷與降級，些時一般採用限流方案來進行保護。限流指的是通過限制到達系統的併發請求數量，保證系統能夠正常響應部分使用...
高併發系統設計方法
在網際網路時代，併發，高併發通常是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。1 qps 每秒查詢率 每秒鐘請求或者查詢的數量，在網際網路領域，指每秒響應請求數 指http請求 2 pv page view 綜合瀏覽量，即頁面瀏覽量或者點選量，乙個訪客在24小時內訪問的頁面數量 3 吞吐量...