本篇章内容为阅读《数据密集型应用系统设计》一书的读书笔记。
作为个人成长学习使用，同时希望对刷到的朋友有所帮助，一起加油哦！

生命就像一朵花，要拼尽全力绽放，芳香四溢，在风中舞蹈！

写在前面：

为什么读这本书？

笔者是一个刚进入数据库行业的幼童，辛得公司指派的一位资深大佬为导师，得导师极力推荐才接触到这本书。在阅读了第一章后，就为书里的内容所折服，里面有很多知识点，需要慢慢读慢慢思考。而且这本书一点也不枯燥，还配了很多图，有些图将技术讲得更清楚易懂，有些图简直美得像艺术品。作者的表达方式我也非常喜欢，语言朴实诚恳（在读的过程中我是真的感觉到非常的诚恳），把跟数据相关的知识点从整体到局部、从浅到深、从各个层次分析讲解得很透彻，是真的让人感觉他想教会我很多知识，用心良苦。在这里真心感谢我的导师，还有作者Martin Kleppmann。作为回报他们最好的方式，就是好好读书，写好读书笔记，能吸收一点是一点。

第一部分 数据系统基础

（图太美了，不得不贴）

我的第一个问题：书名是《数据密集型应用系统设计》，那么首先需要清楚一个概念，什么叫数据密集型应用？（第一章有答案）

数据密集型应用——数据(数据量、数据复杂度、数据变化速度)是主要挑战的这类应用。

计算密集型应用——CPU处理能力是第一限制性因素，计算量大，主要以追求计算速度为主要指标的这类应用。

1可靠、可扩展与可维护的应用系统

1.1 认识数据系统

本书认为数据系统的范围包括：数据库、队列、高速缓存等。

原因：

• 这些用于数据存储和处理的各种工具，不再适合归类为传统系统。

• 单个工具已经不能满足应用系统需求，需要分解任务，由每个工具高效完成各子任务，并依靠应用层代码有组织的衔接起来。

示例：

大多数软件系统都极为重要的三个问题：

1. 可靠性：系统在某些错误（硬件问题、软件故障、人为失误等）情况下仍能正常工作；

1. 可扩展性：系统有合理方式匹配规模（数据量、流量、复杂性等）增长；

1. 可维护性：系统的开发和运维易于掌握。

1.2 可靠性

定义

• 可能出错的事情称为错误或故障；

• 系统可应对错误称为容错或者弹性；

• 容错总是指特定类型的故障，有范围约束；

• 故障与失效不同：故障通常指组件偏离其正常标准；失效意味着系统作为一个整体停止提供服务；

• 我们通常倾向于容忍故障而不是阻止故障，但也有“预防胜于治疗”的情况（比如安全问题）。

硬件故障

通常的解决方法：

• 采用硬件冗余方案，对于大多数应用场景足够。

• 但是，运行在大规模机器上（例如云平台）的应用，通常强调的是总体灵活性与弹性，通过软件容错方式是更有效的手段。（例如单节点停机滚动升级）

软件错误

• 产生原因：系统对使用环境存在某种假设，碰到特定的情况，假设条件不满足，触发bug。（通常长时间处于引而不发的状态）

• 解决办法：无快速解决办法，只能依赖多细节考虑、检查依赖、测试、进程隔离、进程崩溃自动重启、反复评估、监控等手段。

人为失误

• 假定人不可靠，保证系统可靠性的一些方法；

• 以最小出错的方式来设计系统；（抽象层、API、管理界面等，使做正确的事轻松，搞坏很复杂）

• 分离最容易出错的地方、易出故障的接口；（沙箱环境）

• 充分测试；（单元测试、继承测试、手动测试、自动化测试）

• 提供快速的恢复机制减少故障影响；（回滚配置改动、灰度发布、提供校验数据工具）

• 提供有效的监控系统；（监控性能指标、错误率）

• 推行管理流程并培训；

1.3 可扩展性

定义

可扩展性是用来描述系统应对负载增加能力的术语；

描述负载

1. 描述负载的意义：更好的讨论增长问题。

1. 负载：可用负载参数的若干数字来描述，取决于系统体系架构。

描述性能

1. 描述系统负载后，系统在应对负载增加时，有两种考虑方式：

• 负载增加，但系统资源（如CPU、内存、网络带宽等）保持不变，系统性能会发生什么变化？

• 负载增加，如果要保持系统性能不变，需要增加多少资源？

1. 常用性能指标：

• 批处理系统，通常关心吞吐量（throughput）；（每秒可处理的记录条数，或运行所需总时间）

• 在线系统，通常关注服务响应时间(response time)。（客户端从发送请求到接收响应的时间）

1. 响应时间：

• 最好用百分位数，比如 p50（中位数）、p95、p999等，分别表示有50%、95%、99.9%的请求响应时间快于阈值。

1. 响应时间注意点：

• 采用较高的响应时间百分位数（tail latencies，尾部延迟或长尾效应）很重要，因为直接影响用户的总体服务体验；

• 排队延迟往往在高百分数响应时间中影响很大；（可能有队头阻塞、网络延迟等）

• 在客户端来测量响应时间很重要（而不要在服务端）。

应对负载增加的方法

实践中的百分位数：

设置一个10min的滑动窗口，监控其中响应时间，滚动计算窗口中的中位数和各种百分位数，然后绘制性能图标。注意：降低采样时间精度或直接组合来自多台机器的数据，在数学上没有太大意义。

应对负载增加的方法：

• 垂直扩展：升级到更强大的机器；

• 水平扩展：将负载分布到多个更小的机器；（无共享体系结构）

• 自动弹性扩展：自动检测负载增加，自动添加更多计算资源；

• 未来分布式数据系统将成为标配

• 对于尚未定型的产品，应该采取快速迭代推出产品功能，在使用中提高不可知的扩展性。

1.4 可维护性

软件系统的三个设计原则：

• 可维护性：方便运营团队来保持系统平稳运行；

• 简单性：简化系统复杂性，使新工程师能够轻松理解系统；

• 可演化性：后续工程师能够轻松地对系统进行改进、修改、适配业务场景。（可延伸性、易修改性、可塑性）。

可运维性：运维更轻松

• 提供监控系统

• 系统自动化

• 提供良好的文档

• 尝试自我修复

简单性：简化复杂度

• 简化系统设计并不意味着减少系统功能，而主要使消除意外方面的复杂性。

• 消除意外复杂性最好手段之一是抽象。

可演化性：易于改变

简单易懂的系统往往比复杂的系统更容易修改，即可演化性。

2 数据模型与查询语言

3 数据存储与检索

4 数据编码与演化