diff --git a/ch01.md b/ch01.md index 384b60f..bbd49f6 100644 --- a/ch01.md +++ b/ch01.md @@ -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/)。 @@ -80,15 +80,12 @@ - **MTTF mean time to failure** 单块盘 平均故障时间 5 ~10 年，如果你有 1w+ 硬盘，则均匀期望下，每天都有坏盘出现。当然事实是硬盘会一波一波坏。 -解决办法，增加冗余度： - -机房多路供电，双网络等等。 +解决办法，增加冗余度：机房多路供电，双网络等等。 对于数据： -**单机**：可以做 RAID 冗余。如：EC 编码。 - -**多机**：多副本 or EC 编码。 +* **单机**：可以做 RAID 冗余。如：EC 编码。 +* **多机**：多副本 或 EC 编码。 ## 软件错误 @@ -118,15 +115,15 @@ 3. 报警机制 4. 问题预案 - **针对组织** - 科学的培训和管理 + 1. 科学的培训和管理 ## 可靠性有多重要？ 事关用户数据安全，事关企业声誉，企业存活和做大的基石。 -# 可伸缩性 +# 可扩展性 -可伸缩性，即系统应对负载增长的能力。它很重要，但在实践中又很难做好，因为存在一个基本矛盾：**只有能存活下来的产品才有资格谈伸缩，而过早为伸缩设计往往活不下去**。 +可扩展性，即系统应对负载增长的能力。它很重要，但在实践中又很难做好，因为存在一个基本矛盾：**只有能存活下来的产品才有资格谈扩展，而过早为扩展设计往往活不下去**。 但仍是可以了解一些基本的概念，来应对**可能会**暴增的负载。 @@ -171,12 +168,12 @@ ## 应对负载 -在有了描述和定义负载、性能的手段之后，终于来到正题，如何应对负载的不断增长，即使系统具有可伸缩性。 +在有了描述和定义负载、性能的手段之后，终于来到正题，如何应对负载的不断增长，即使系统具有可扩展性。 -1. **纵向伸缩（scaling up）or 垂直伸缩（vertical scaling）**：换具有更强大性能的机器。e.g. 大型机机器学习训练。 -2. **横向伸缩（scaling out）or 水平伸缩（horizontal scaling）**：“并联”很多廉价机，分摊负载。e.g. 马斯克造火箭。 +1. **纵向扩展（scaling up）或 垂直扩展（vertical 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）_** 便于后面需求快速适配：避免耦合过紧，将代码绑定到某种实现上。也称为**可扩展性（extensibility）**，**可修改性（modifiability）**  或**可塑性（plasticity）**。 -## **可运维性（Operability）：人生苦短，关爱运维** +## **可维护性（Operability）：人生苦短，关爱运维** 有效的运维绝对是个高技术活：