工作3年左右面試通常會被問到這個問題。我之前也被問到過這個問題，感覺自己回答的點不夠全面，現在重新整理下，包含不限於以下幾點：
**1》框架設計：對專案拆分成功能單一小專案（參考購物**），使用分布式框架，如：dubbo框架，微服務框架。
2》資料庫：資料庫集群部署，主備設計，讀寫分離，對資料量大讀寫操作頻繁的表進行分庫分表。
3》資料量不大且常用的資料使用快取（如redis）。
4》多用非同步請求，少用同步請求。（需要返回結果執行下一步的必須使用同步請求）
5》減少不必要的資料請求（包括對資料庫的請求）。
6》儲存在oss伺服器上。
7》使用反向**伺服器，減輕伺服器壓力。
8》增強硬體支援，提高頻寬，多台伺服器集群部署。
9》表連線較多的查詢統計使用冗餘表。
10》使用執行緒池，nginx反向**伺服器**
如何設計乙個高併發系統
總結如果你確實有真才實學，在網際網路公司裡幹過高併發系統，那你確實拿 offer 基本如探囊取物，沒啥問題。面試官也絕對不會這樣來問你，否則他就是蠢。假設你在某知名電商公司幹過高併發系統，使用者上億，一天流量幾十億，高峰期併發量上萬，甚至是十萬。那麼人家一定會仔細盤問你的系統架構，你們系統啥架構？怎...
如何設計乙個高併發系統
系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以抗高併發麼。快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發...
如何設計乙個高可用 高併發秒殺系統
如今的網際網路已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 0 到 1 完整踐行海量服務。微視春節專案中的集卡瓜分活動，是乙個典型的秒殺場景，自己參與其中，分享一些心得和總結。上圖是乙個典型的網際網路業務，使用者完成乙個寫操作，一般會通過接入層和邏輯層，這裡的服務都是無狀態，可以通過...