> For the complete documentation index, see [llms.txt](https://wtifs.gitbook.io/diva-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wtifs.gitbook.io/diva-notes/system-design/gao-bing-fa-gao-ke-yong.md).

# 高并发高可用

## 高并发

一般和高性能一起讲

**设计层面**

* 网关：负载均衡
* 服务分布式化、无状态化，支持水平弹性扩容
* 使用缓存，多级缓存
* 调用链路热点前置（如CDN
* 提前容量规划（如使用商品预约功能预估流量
* 前后端限频、网关限流，阻拦不合理流量，避免不合理流量影响性能

**代码层面**

* fail fast 快速失败
* 可以做并行的地方并行化、异步化，不要用串行逻辑
* 减小锁粒度；利用分片减小锁范围或无锁化
* 本地缓存
* 合并连续请求，一次性批量处理，减小网络传递流量

**数据库**

* 根据不同的存储诉求来进行不同的存储选型
* 设计合理的索引，利用覆盖索引避免回表、排序等
* 分库分表、读写分离、数据分片
* 热点数据拆分、隔离、分片

## 高可用

先明确概念：部分节点挂掉的情况下，仍能提供全部/正常服务

总体思路：1. 预防，2. 容灾（服务&存储、运维）

* 预防
  * 代码规范
  * 单测：减少 bug，提高健壮性
  * 日志：设计良好的日志能加速发现问题
  * 做好容量规划和评估，对系统要抗住的量级有基本认知，以便设计合理的架构和演进
  * 做好压测
* 服务与存储
  * 框架有服务治理的功能：
    * 网关：负载均衡、健康检查、故障转移
    * 阻拦不合理流量：鉴权、登录态检查、限流
    * 过载保护：熔断（保护下游）、降级（保证核心功能可用）
  * 异步解耦和削峰设计
    * 异步解耦：如果消费方异常，并不影响生产方，生产方依然可以对外提供服务。消费者恢复后可以继续从消息队列里面消费数据
    * 削峰：不会因为有突发流量而把整个系统打垮
  * 网关、服务、存储都需要多节点冗余，将单点结构转为多点结构，提高可用性
* 存储层面
  * 集中式存储
    * DB主备、主备切换
    * 业务隔离，分库分表
  * 分布式存储
    * HDFS、HBase、ES 等
  * 缓存
    * Redis 使用哨兵或集群模式
* 运维层面
  * 自动化CICD：自动化测试、部署；灰度发布（金丝雀发布）、蓝绿发布（新建容器发布后切换）
  * 监控与告警（prometheus + grafana），及时预警和发现故障
  * 容灾
    * 多机房部署
  * 故障演练/接口拨测
    * 接口拨测和巡检类似，每隔一个固定时间调用后端的各种接口，如果接口异常则进行告警
* 产品层面
  * 兜底策略
    * 比如页面获取不到数据的时候，或者无法访问的时候，要如何友好的告知用户，比如【稍后重试】之类的。
    * 比如页面无法访问的时候，那么需要产品提供一个默认页面，如果后端无法获取真实数据，那么直接渲染默认页面
    * 比如服务器需要停机维护，那么产品层面给一个停机页面，所有用户只会弹出这个停机页面，不会请求后端服务
* 应急预案
  * 出现问题后怎么快速恢复，不至于让异常事态扩大
  * 依赖的其他服务出现问题的时候，要尽快的进行降级、兜底等各种异常保护措施

#### 参考

[AllenWu - 工作十年，谈谈我的高可用架构和系统设计经验](https://mp.weixin.qq.com/s?__biz=MzkyNTI5NTQ1NQ==\&mid=2247511260\&idx=1\&sn=74b94bfb54993cef6d92d00471cc20c7\&chksm=c1ca5aecf6bdd3fa7da88ac44ca21fd6ae792afc8ab0e9ac6ea17c4528dac9182d54b0b427d4\&scene=126\&sessionid=0)