分布式系统¶
系统突发十倍流量¶
- 限流降级，超过承载能力的请求快速失败，同时业务降级，关闭推荐等非核心业务，同时调度k8s扩容增加容量。
- 如果这种流量常态化，则通过多级缓存、读写分离、异步处理、弹性容器化、限流熔断、系统状态监测、压测等方式保障系统稳定性
负载均衡¶
负载均衡¶
- 硬件：F5
- 软件
- LVS（四层）
- Nginx / HAProxy（七层）
- DNS（DNS 轮询）
单体服务拆分为微服务¶
- 梳理业务模块、重要性、紧急程度等排出迁移优先级
- 先用职责清晰，功能简单的模块（如用户管理等）拆分验证，把注册中心、配置中心、网关、监控等基础设施搭建好，方便之后的模块迁移
- 整个迁移过程采用渐进式、小步快跑、灰度发布、回滚预案等策略，减少风险
客户说接口超时，如何排查？¶
全局->局部->日志，关注数据库、下游服务、网络、代码等
- 先确定是偶发还是持续超时，提供请求ID或具体时间，是个别用户还是全部用户
- 查看监控指标，关注接口的响应时间、QPS、错误率等，同时查看服务器的CPU、内存、网络等资源使用情况
- 使用请求ID查看日志，查看每个环节的处理时间，逐步缩小排查范围
- 数据库的话查看慢查询日志，是否命中索引、命中缓存等
- 确定问题后，快速处理，比如增加索引、增加缓存、扩容、熔断降级等，优先保证服务恢复，后续做完整复盘，并采取措施（如告警、压测等）避免此类问题
未支付取消订单¶
- 定时轮询：简单但精度低，并且对DB持续压力
- Redis Key 过期监听：实现简单，但过期通知基于 Pub/Sub，不持久化、不重试，监听服务宕机则事件永久丢失，可靠性差
- MQ 延迟队列（推荐）：消息持久化 + ACK 确认，可靠性高，精度好；缺点是引入 MQ 增加了架构复杂度和运维成本
点赞系统¶
- Redis的集合：在点赞时，将用户的ID存入集合，在取消点赞时，将用户的ID从集合中删除；通过
scard即可得知点赞人数 - 同步到DB：通过MQ异步批量写入DB
- 热点Key：明星可能短时间内被很多人点赞，可以在代码中维护一个本地缓存，把热点Key批量插入Redis
短链接系统¶
使用自增ID + Base62，ID对62取模后产生所需的唯一短链接。
使用临时重定向，方便跟踪和分析链接使用情况。