最近在准备面试，正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解，以及高频业务场景的应对策略系统梳理一遍，既能加深记忆，也能让知识体系更扎实，供大家参考，欢迎讨论。
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 横向伸缩应对突发流量。
- 应用锁：限制只有少量节点回源数据库，防止缓存击穿。