最近在準備面試，正把平時積累的筆記、項目中遇到的問題與解決方案、對核心原理的理解，以及高頻業務場景的應對策略系統梳理一遍，既能加深記憶，也能讓知識體系更扎實，供大家參考，歡迎討論。
1. 微服務拆分
- Spring Cloud 微服務架構，將業務按功能模塊和熱點服務拆分：
學員端、助教端、講師端、管理端、直播渠道網關、直播消息、直播營銷、直播視頻、直播網關（接收渠道回調）、直播socket、錄播推流服務等。 - Job 單獨拆分：定時任務 Job 服務（計費，自動開播等）獨立部署，避免和業務服務耦合，防止 Job 的 CPU/內存抖動影響用戶請求。
- 服務拆分優勢：
熱點服務可單獨高配與水平擴展，避免功能間相互影響，從而提升系統的高可用性與擴展性。同時通過服務解耦，避免如消息功能依賴的 ES 掛掉時，影響其他核心功能。
2. 部署與擴展
- Kubernetes 部署：所有服務以 Pod 形式運行，支持彈性伸縮（HPA），應對突發流量。
- 多實例部署：Nginx / Ingress 做負載均衡，分攤請求，避免單點瓶頸。
- 監控與告警：接入阿里云日志和 Prometheus，根據接口響應時間（>3s）觸發告警（日志服務告警功能的應用場景）。
3. 緩存策略
- 分布式緩存：讀請求優先查 Redis，緩存未命中時訪問數據庫并回填緩存。
- 應用鎖防擊穿：使用ReentrantLock（可重入鎖），限制只有少量節點能回源數據庫，其余節點直接等待緩存填充，避免緩存擊穿。
- 異步刷新：熱點數據支持定時刷新 / 事件驅動刷新 Redis，降低實時 DB 依賴。
4. 消息隊列（MQ）
- 解耦：登錄成功操作，通過 MQ 投遞消息，下游（SCRM 客戶維護、報表系統等）各自消費，降低耦合度。
- 削峰，異步寫 DB：高頻寫場景（如簽到），先入 MQ，再后臺消費寫庫，避免數據庫直接承壓和接口請求超時。
5. 數據庫優化
- 分庫分表（ShardingJDBC）：SAAS平臺按公司 ID 取模水平拆分，突破單庫瓶頸。
- 讀寫分離：MySQL 主從架構，主庫負責寫，從庫負責讀，可根據業務發展水平擴展。
- 冷熱分離：歷史數據定期歸檔，保持在線表輕量化。如直播學員觀看記錄，結算后歸檔歷史庫，減少在線庫壓力。
6. 搜索與統計
- Elasticsearch：承載直播消息全文檢索與復雜查詢/統計，分布式可擴容，天然支持高并發。
7. 限流與熔斷
- 限流：接口支持使用 Redisson 的 RRateLimiter 進行分布式限流，同時可以通過白名單機制對特定 IP 免限流。
- 熔斷：通過 Hystrix 實現服務熔斷、降級和隔離，保證在部分下游服務故障時系統仍能穩定運行，避免單個服務拖垮整體。
8. 核心總結
- 緩存：承載高并發讀場景。
- MQ：削峰 & 解耦，承載高并發寫場景。
- 分庫分表 & 讀寫分離：突破單庫限制。
- ES：查詢/搜索高并發支撐。
- K8s 彈性擴容：Pod 橫向伸縮應對突發流量。
- 應用鎖：限制只有少量節點回源數據庫，防止緩存擊穿。
