Update ch01.md

This commit is contained in:
Steam 2023-06-21 16:41:21 +08:00 committed by GitHub
parent 8037dfccf4
commit 0c4041516e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

35
ch01.md
View File

@ -41,7 +41,7 @@
因此,有必要从根本上思考下如何评价一个好数据系统,如何构建一个好的数据系统,有哪些可以遵循的设计模式?有哪些通常需要考虑的方面? 因此,有必要从根本上思考下如何评价一个好数据系统,如何构建一个好的数据系统,有哪些可以遵循的设计模式?有哪些通常需要考虑的方面?
书中用了三个词来回答:**可靠性Reliability、可伸缩Scalability、可维护性Maintainability** 书中用了三个词来回答:**可靠性Reliability、可扩展Scalability、可维护性Maintainability**
# 可靠性 # 可靠性
@ -59,9 +59,9 @@
--- ---
两个易混淆的概念:**Fault系统出现问题** and **Failure系统不能提供服务** 两个易混淆的概念:**Fault系统出现问题** **Failure系统不能提供服务**
不能进行 Fault-tolerance 的系统,积累的 fault 多了,就很容易 Failure。 不能进行 Fault-tolerance 的系统,积累的 fault 多了,就很容易 failure。
如何预防?混沌测试:如 Netflix 的 [chaosmonkey](https://netflix.github.io/chaosmonkey/)。 如何预防?混沌测试:如 Netflix 的 [chaosmonkey](https://netflix.github.io/chaosmonkey/)。
@ -80,15 +80,12 @@
- **MTTF mean time to failure** - **MTTF mean time to failure**
单块盘 平均故障时间 5 ~10 年,如果你有 1w+ 硬盘,则均匀期望下,每天都有坏盘出现。当然事实是硬盘会一波一波坏。 单块盘 平均故障时间 5 ~10 年,如果你有 1w+ 硬盘,则均匀期望下,每天都有坏盘出现。当然事实是硬盘会一波一波坏。
解决办法,增加冗余度: 解决办法,增加冗余度:机房多路供电,双网络等等。
机房多路供电,双网络等等。
对于数据: 对于数据:
**单机**:可以做 RAID 冗余。如EC 编码。 * **单机**:可以做 RAID 冗余。如EC 编码。
* **多机**:多副本 或 EC 编码。
**多机**:多副本 or EC 编码。
## 软件错误 ## 软件错误
@ -118,15 +115,15 @@
3. 报警机制 3. 报警机制
4. 问题预案 4. 问题预案
- **针对组织** - **针对组织**
科学的培训和管理 1. 科学的培训和管理
## 可靠性有多重要? ## 可靠性有多重要?
事关用户数据安全,事关企业声誉,企业存活和做大的基石。 事关用户数据安全,事关企业声誉,企业存活和做大的基石。
# 可伸缩 # 可扩展
伸缩性,即系统应对负载增长的能力。它很重要,但在实践中又很难做好,因为存在一个基本矛盾:**只有能存活下来的产品才有资格谈伸缩,而过早为伸缩设计往往活不下去**。 扩展性,即系统应对负载增长的能力。它很重要,但在实践中又很难做好,因为存在一个基本矛盾:**只有能存活下来的产品才有资格谈扩展,而过早为扩展设计往往活不下去**。
但仍是可以了解一些基本的概念,来应对**可能会**暴增的负载。 但仍是可以了解一些基本的概念,来应对**可能会**暴增的负载。
@ -171,12 +168,12 @@
## 应对负载 ## 应对负载
在有了描述和定义负载、性能的手段之后,终于来到正题,如何应对负载的不断增长,即使系统具有可伸缩性。 在有了描述和定义负载、性能的手段之后,终于来到正题,如何应对负载的不断增长,即使系统具有可扩展性。
1. **纵向伸缩scaling upor 垂直伸缩vertical scaling**换具有更强大性能的机器。e.g. 大型机机器学习训练。 1. **纵向扩展scaling up或 垂直扩展vertical scaling**换具有更强大性能的机器。e.g. 大型机机器学习训练。
2. **横向伸缩scaling outor 水平伸缩horizontal scaling**“并联”很多廉价机分摊负载。e.g. 马斯克造火箭。 2. **横向扩展scaling out或 水平扩展horizontal scaling**“并联”很多廉价机分摊负载。e.g. 马斯克造火箭。
负载伸缩的两种方式: 负载扩展的两种方式:
- **自动** - **自动**
如果负载不好预测且多变,则自动较好。坏处在于不易跟踪负载,容易抖动,造成资源浪费。 如果负载不好预测且多变,则自动较好。坏处在于不易跟踪负载,容易抖动,造成资源浪费。
@ -187,9 +184,9 @@
首先,如果规模很小,尽量还是用性能好一点的机器,可以省去很多麻烦。 首先,如果规模很小,尽量还是用性能好一点的机器,可以省去很多麻烦。
其次,可以上云,利用云的可伸缩性。甚至如 Snowflake 等基础服务提供商也是 All In 云原生。 其次,可以上云,利用云的可扩展性。甚至如 Snowflake 等基础服务提供商也是 All In 云原生。
最后,实在不行再考虑自行设计可伸缩的分布式架构。 最后,实在不行再考虑自行设计可扩展的分布式架构。
两种服务类型: 两种服务类型:
@ -213,7 +210,7 @@
- **_可演化性Evolvability_** - **_可演化性Evolvability_**
便于后面需求快速适配:避免耦合过紧,将代码绑定到某种实现上。也称为**可扩展性extensibility****可修改性modifiability**  或**可塑性plasticity**。 便于后面需求快速适配:避免耦合过紧,将代码绑定到某种实现上。也称为**可扩展性extensibility****可修改性modifiability**  或**可塑性plasticity**。
## **可维性Operability人生苦短关爱运维** ## **可维Operability人生苦短关爱运维**
有效的运维绝对是个高技术活: 有效的运维绝对是个高技术活: