mirror of
https://github.com/CyC2018/Interview-Notebook.git
synced 2026-10-24 18:23:43 +00:00
Update 系统设计基础.md
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
88b5227bb7
commit
da3364c448
+16
-9
@@ -18,19 +18,19 @@
|
||||
|
||||
指某个请求从发出到接收到响应消耗的时间。
|
||||
|
||||
在对响应时间进行测试时,通常采用重复请求的方式,然后计算平均响应时间。
|
||||
在对响应时间进行测试时,通常采用重复请求的方式,然后计算平均响应时间。平均值会掩盖少数很慢的请求,因此也常用 P99 等分位值来衡量。
|
||||
|
||||
#### 2. 吞吐量
|
||||
|
||||
指系统在单位时间内可以处理的请求数量,通常使用每秒的请求数来衡量。
|
||||
指系统在单位时间内可以处理的请求数量,通常使用每秒的请求数(QPS)来衡量。
|
||||
|
||||
#### 3. 并发用户数
|
||||
|
||||
指系统能同时处理的并发用户请求数量。
|
||||
|
||||
在没有并发存在的系统中,请求被顺序执行,此时响应时间为吞吐量的倒数。例如系统支持的吞吐量为 100 req/s,那么平均响应时间应该为 0.01s。
|
||||
三者的关系为:并发数 = 吞吐量 × 响应时间。在没有并发存在的系统中,请求被顺序执行,此时响应时间为吞吐量的倒数。例如系统支持的吞吐量为 100 req/s,那么平均响应时间应该为 0.01s。
|
||||
|
||||
目前的大型系统都支持多线程来处理并发请求,多线程能够提高吞吐量以及缩短响应时间,主要有两个原因:
|
||||
目前的大型系统都支持多线程来处理并发请求,多线程能够提高吞吐量,主要有两个原因:
|
||||
|
||||
- 多 CPU
|
||||
- IO 等待时间
|
||||
@@ -61,6 +61,9 @@
|
||||
|
||||
指不断向集群中添加服务器来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
|
||||
|
||||
- 垂直伸缩:提升单台服务器的硬件配置,存在上限;
|
||||
- 水平伸缩:增加服务器的数量,是大型系统的主要方式。
|
||||
|
||||
### 伸缩性与性能
|
||||
|
||||
如果系统存在性能问题,那么单个用户的请求总是很慢的;
|
||||
@@ -71,7 +74,7 @@
|
||||
|
||||
应用服务器只要不具有状态,那么就可以很容易地通过负载均衡器向集群中添加新的服务器。
|
||||
|
||||
关系型数据库的伸缩性通过 Sharding 来实现,将数据按一定的规则分布到不同的节点上,从而解决单台存储服务器的存储空间限制。
|
||||
关系型数据库通常先通过主从复制实现读写分离来分担读压力,再通过 Sharding 将数据按一定的规则分布到不同的节点上,从而解决单台存储服务器的存储空间限制。
|
||||
|
||||
对于非关系型数据库,它们天生就是为海量数据而诞生,对伸缩性的支持特别好。
|
||||
|
||||
@@ -86,25 +89,29 @@
|
||||
|
||||
## 四、可用性
|
||||
|
||||
可用性用系统可用时间占总时间的比值来衡量,4 个 9 表示系统 99.99% 的时间是可用的,一年的不可用时间不超过 53 分钟。
|
||||
|
||||
### 冗余
|
||||
|
||||
保证高可用的主要手段是使用冗余,当某个服务器故障时就请求其它服务器。
|
||||
|
||||
应用服务器的冗余比较容易实现,只要保证应用服务器不具有状态,那么某个应用服务器故障时,负载均衡器将该应用服务器原先的用户请求转发到另一个应用服务器上,不会对用户有任何影响。
|
||||
|
||||
存储服务器的冗余需要使用主从复制来实现,当主服务器故障时,需要提升从服务器为主服务器,这个过程称为切换。
|
||||
存储服务器的冗余需要使用主从复制来实现,当主服务器故障时,需要提升从服务器为主服务器,这个过程称为故障转移(Failover)。
|
||||
|
||||
### 监控
|
||||
|
||||
对 CPU、内存、磁盘、网络等系统负载信息进行监控,当某个信息达到一定阈值时通知运维人员,从而在系统发生故障之前及时发现问题。
|
||||
|
||||
### 服务降级
|
||||
### 限流、降级与熔断
|
||||
|
||||
服务降级是系统为了应对大量的请求,主动关闭部分功能,从而保证核心功能可用。
|
||||
- 限流:请求量超过系统的处理能力时,拒绝多余的请求,常用令牌桶和漏桶算法;
|
||||
- 降级:主动关闭部分非核心功能,从而保证核心功能可用;
|
||||
- 熔断:某个依赖的服务持续出错时,暂时不再调用它而是直接返回默认结果,避免故障沿着调用链扩散。
|
||||
|
||||
## 五、安全性
|
||||
|
||||
要求系统在应对各种攻击手段时能够有可靠的应对措施。
|
||||
要求系统在应对各种攻击手段时能够有可靠的应对措施,常见的攻击手段和防范方法见 [攻击技术](攻击技术.md)。
|
||||
|
||||
## 参考资料
|
||||
|
||||
|
||||
Reference in New Issue
Block a user