公升級過程為：最初系統——新增負載均衡——資料庫分庫分表+讀寫分離——快取集群+訊息中介軟體集群
假設系統機器是4核8g，資料庫伺服器是16核32g。日活使用者1w，系統層面每秒10次請求，資料庫層每秒30次請求。
使用者量增長了50倍，日活使用者50萬，高峰期對系統每秒請求500/s，對資料庫的每秒請求1500/s
問題：系統cpu負載過高，資料庫可以接受
使用者量繼續增長，達到了1000萬註冊使用者，每天日活使用者是100萬。
問題：系統層面可以通過負載均衡解決，資料庫層面接受的請求量達到3000/s會負載過高。
使用者量繼續增長。
資料庫擴容成本高。
讀多寫少的壓力：快取集群
在寫資料庫的時候同時寫乙份資料到快取集群裡，然後用快取集群來承載大部分的讀請求。
高寫入的壓力：訊息中介軟體集群
將寫請求非同步化處理。允許非同步化的每秒 500 次請求寫入 mq，然後基於 mq 做乙個削峰填谷。以平穩的 100/s 的速度消費出來，然後落入資料庫中。
如何設計乙個高併發系統
總結如果你確實有真才實學，在網際網路公司裡幹過高併發系統，那你確實拿 offer 基本如探囊取物，沒啥問題。面試官也絕對不會這樣來問你，否則他就是蠢。假設你在某知名電商公司幹過高併發系統，使用者上億，一天流量幾十億，高峰期併發量上萬，甚至是十萬。那麼人家一定會仔細盤問你的系統架構，你們系統啥架構？怎...
如何設計乙個高併發系統
系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以抗高併發麼。快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發...
如何設計乙個高可用 高併發秒殺系統
如今的網際網路已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 0 到 1 完整踐行海量服務。微視春節專案中的集卡瓜分活動，是乙個典型的秒殺場景，自己參與其中，分享一些心得和總結。上圖是乙個典型的網際網路業務，使用者完成乙個寫操作，一般會通過接入層和邏輯層，這裡的服務都是無狀態，可以通過...