DDIA阅读学习笔记

• 1. 背景
• 2. 数据系统基础
  • 2.1. 可靠性，可伸缩性和可维护性
• 3. 小结
• 4. 参考

DDIA（《Designing Data-Intensive Applications》）阅读学习笔记。

1. 背景

阅读经典书籍并反馈输出笔记，本篇起阅读学习《Designing Data-Intensive Applications》（《设计数据密集型应用》）。

书籍赞誉很多，简介：

《设计数据密集型应用》（Designing Data-Intensive Applications，简称 DDIA），作者是 Martin Kleppmann，他是剑桥大学分布式系统的研究员（现在是副教授），此前在 LinkedIn 和 Rapportive 负责大规模数据基础架构，是一位常规会议演讲者、博主和开源贡献者。

这是一本理论结合实践的书，本书从底层数据结构到顶层架构设计，将数据系统设计中的精髓娓娓道来。其中的宝贵经验无论是对架构师、DBA、还是后端工程师、甚至产品经理都会有帮助。

这本书应该是软件工程师的必读之书。数据的爆炸式增长及其对我们所构建应用程序的重要性日益增加，带来了一系列新的复杂挑战。《设计数据密集型应用》是一本罕见的将理论与实践相结合的书籍，有助于开发人员在设计和实现数据基础设施和系统时做出明智的决策。

学习参考：

• 设计数据密集型应用 - 中文翻译
• 《DDIA 逐章精读》小册

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）
• 可伸缩性（Scalability）：有合理的办法应对系统的负载增长（数据量、流量、复杂性）
  • 描述负载：使用一些称为 负载参数（load parameters） 的数字来描述，参数的最佳选择取决于系统架构
  • 描述性能
    • 吞吐量（throughput），每秒可以处理的记录数量；
    • 响应时间（response time），客户端发送请求到接收响应之间的时间，除了实际处理时间外还包括了网络延迟（latency）和排队延迟。延迟期间请求处于休眠（latent）状态。
    • 相对于平均响应时间（mean），百分位点（percentiles）会是更好的衡量标准。其中中位数（median）表示50百分位，缩写为p50。
    • 响应时间的高百分位点（也称为 尾部延迟，即 tail latencies）非常重要，因为它们直接影响用户的服务体验。
    • 百分位点通常用于 服务级别目标（SLO, service level objectives） 和 服务级别协议（SLA, service level agreements），即定义服务预期性能和可用性的合同。
  • 应对负载
    • scaling up
      • 纵向伸缩（scaling up，也称为垂直伸缩，即 vertical scaling，转向更强大的机器）
    • scaling out
      • 横向伸缩（scaling out，也称为水平伸缩，即 horizontal scaling，将负载分布到多台小机器上）
    • shared-nothing
      • 跨多台机器分配负载也称为 “无共享（shared-nothing）” 架构
      • 在一个分布式系统中，每个计算节点都有自己的私有资源，包括 CPU、内存、磁盘存储等。每个节点独立地执行任务，任务之间不共享这些资源，节点间通过协议通信。
      • 对比而言shared-everything：在分布式存储中，是指软件架构中每个元数据控制器节点上的 chunkserver（数据持久层服务），都可以直接访问所有存储节点上的 SSD，从而提高了数据访问速度和灵活性。
    • 弹性（elastic）：检测到负载增加时自动增加计算资源
    • 无状态服务（stateless services），将带状态的数据系统从单节点变为分布式配置则可能引入许多额外复杂度
• 可维护性（Maintainability）：许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）

3. 小结

4. 参考

• 设计数据密集型应用 - 中文翻译
• 《DDIA 逐章精读》小册