DDIA（《Designing Data-Intensive Applications》）阅读学习笔记。
1. 背景
阅读经典书籍并反馈输出笔记，本篇起阅读学习《Designing Data-Intensive Applications》（《设计数据密集型应用》）。
参考：
2. 数据系统基础
2.1. 可靠性，可伸缩性和可维护性
现今很多应用程序都是 数据密集型（data-intensive） 的，而非 计算密集型（compute-intensive） 的。因此 CPU 很少成为这类应用的瓶颈，更大的问题通常来自数据量、数据复杂性、以及数据的变更速度。
数据密集型应用通常由标准组件构建而成，标准组件提供了很多通用的功能：
- 数据库（database）
- 缓存（cache）
- 搜索索引（search indexes）
- 流处理（stream processing）
- 批处理（batch processing）
设计数据系统或服务时可能会遇到很多棘手的问题，例如：
- 当系统出问题时，如何确保数据的正确性和完整性？
- 当部分系统退化降级时，如何为客户提供始终如一的良好性能？
- 当负载增加时，如何扩容应对？
- 什么样的 API 才是好的 API？
影响数据系统设计的因素很多，本书着重讨论三个在大多数软件系统中都很重要的问题：
- 可靠性（Reliability）：系统在
困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）- fault 和 failure
- 造成错误的原因叫做
故障（fault），能预料并应对故障的系统特性可称为容错（fault-tolerant）或韧性（resilient） - 注意 故障（fault） 不同于 失效（failure）。
故障通常定义为系统的一部分状态偏离其标准，失效表示系统作为一个整体停止向用户提供服务 故障（fault）的概率不可能降到零，因此最好设计容错机制以防因故障而导致失效（failure）
- 造成错误的原因叫做
- fault 和 failure
- 可伸缩性（Scalability）：有合理的办法应对系统的负载
增长（数据量、流量、复杂性）- 描述
负载：使用一些称为负载参数（load parameters）的数字来描述，参数的最佳选择取决于系统架构 - 描述
性能吞吐量（throughput），每秒可以处理的记录数量；响应时间（response time），客户端发送请求到接收响应之间的时间，除了实际处理时间外还包括了网络延迟（latency）和排队延迟。延迟期间请求处于休眠（latent）状态。
- 描述
- 可维护性（Maintainability）：许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）
