这本书一直在我的待读列表，但是一直没有机会拜读，直到最近 2021 年已经快要过去，感觉需要在年末提升一下自己。边读边做一下笔记，留待后用。
数据密集型与计算密集型
对于一个应用系统，如果”数据”是其成败决定性因素，包括数据的规模、数据的复杂度或者数据产生与变化的速率等，我们就可以称为”数据密集型(Data-Intensive)应用系统”。与之对应的是计算密集型(Compute-Intensive)，CPU 主频往往是其最大的制约瓶颈。
内容安排
全书分为三大部分:
- 主要讨论有关增强数据密集型应用系统所需的若干基本原则
- 我们将从单机的数据存储转向跨机器的分布式系统，将依次讨论数据远程复制、数据分区、事务、分布式系统的更多细节以及分布式环境如何达成一致性与共识
- 主要针对产生派生数据的系统(所谓派生数据主要指在异构系统中，如果无法用一个数据源来解决所有问题，那么一种自然的方式就是集成多个不同的数据库、缓存模块以及索引模块)
可靠、可扩展与可维护的应用系统
第一章主要介绍相关术语与方法， 这些术语等将贯穿于全书。
- 可靠性: 当出现意外情况如硬件、软件故障、人为失误等，系统应可以继续正常运转，虽然性能可能有所降低，但确保功能正确
- 可扩展性: 随着规模的增长，例如数据量、流量或复杂性，系统应以合理的方式来匹配这种增长
- 可维护性: 随着时间的推移，许多新的入员参与到系统开发和运维，以维护现有功能或适配新场景等，系统都应高效运转
可靠性
- 应用程序执行用户所期望的功能
- 可以容忍用户出现错误或者不正确的软件使用方法
- 性能可以应对典型场景、合理负载压力和数据量
- 系统可防止任何未经授权的访问和滥用
可能出错的事情称为错误或故障，系统可应对错误则称为容错或弹性。
需要注意: 容错并不是指系统可以容忍各种可能的故降类型，而是指特定类型的故障。
在这种容错系统中，用于测试目的，可以故意提高故障发生概率，例如通过随机杀死某个进程，来确保系统仍保持健壮。通过这种故意引发故障的方式，来持续检验、测试系统的容错机制，增加对真实发生故障时应对的信心。
硬件故障
当我们考虑系统故障时，硬件故障包括: 硬盘崩溃，内存故障，电网停电，甚至误拔网线。应通常是为硬件添加冗余来减少系统故陪率。
软件错误
另一类故障则是系统内的软件问题，这些故障事先更加难以预料，而且因为节点之间是由软件关联的，因而往往会导致更多的系统故障。软件系统问题有时没有快速解决办法，而只能仔细考虑很多细节，包括认真检查依赖的假设条件与系统之间交互，进行全面的测试，进程隔离，允许进程崩溃并自动重启，反复评估，监控并分析生产环节的行为表现等。
人为失误
设计和构建软件系统总是由人类完成，也是由人来运维这些系统。人无法做到万无一失，例如，一项针对大型互联网服务的调查发现，运维者的配置错误居然是系统下线的首要原因。
如果我们假定入是不可靠的，那么该如何保证系统的可靠性呢，可以尝试结合以下多种方法:
- 以最小出错的方式来设计系统。例如，精心设计的抽象层、API 以及管理界面
- 想办法分离最容易出错的地方、容易引发故障的接口
- 充分的测试，从各单元测试到系统集成测试以及手动测试
- 当出现人为失误时，提供快速的恢复机制以尽最减少故障影响。例如，快速回滚配置改动，滚动发布新代码等
- 设置详细而清晰的监控子系统，包括性能指标和错误率
- 推行管理流程并加以培训
可靠性的重要性
很多应用都需要可靠工作，商业软件中的错误会导致效率下降，电子商务网站的暂停会对营收和声誉带来巨大损失。即使在所谓”非关键”应用中，我们也应秉持对用户负责的态度。
可扩展性
即使系统现在工作可靠，并不意味着它将来一定能够可靠运转。发生退化的一个常见原因是负载增加，服务一个客户和服务一万个客户，要处理的数据量也完全是几何级增长。
描述负载
首先，我们需要简洁地描述系统当前的负载，只有这样才能更好地讨论后续增长问题。负载可以用称为负载参数的若干数字来描述。参数的最佳选择取决于系统的体系结构:
- 可能是Web服务器的每秒请求处理次数
- 数据库中写入的比例
- 聊天室的同时活动用户数量
- 缓存命中率
有时平均值很重要，有时系统瓶颈来自于少数峰值。
描述性能
描述系统负载之后，接下来设想如果负载增加将会发生什么。有两种考虑方式:
- 负载增加，但系统资源(如 CPU、内存、网络带宽等)保持不变，系统性能会发生什么变化
- 负载增加，如果要保持性能不变，需要增加多少资源
在批处理系统如 Hadoop 中，我们通常关心吞吐量(throughput)，即每秒可处理的记录条数，或者在某指定数据集上运行作业所需的总时间。
而在线系统通常更看重服务的响应时间(response time)，即客户端从发送请求到接收响应之间的间隔。
注意: 我们经常考察的是服务请求的平均响应时间，然而，如果想知道更典型的响应时间，平均值并不是合适的指标。最好使用百分位数(percentiles)。如果已经搜集到了响应时间信息，将其从最快到最慢排序，中位数(median)就是列表中间的响应时间。中位数指标非常适合描述多少用户需要等待多长时间：一半的用户请求的服务时间少于中位数响应时间，另一半则多于中位数的时间。因此中位数也称为 50 百分位数，可缩写为 p5O。
当然为了弄清楚异常值有多槽糕，需要关注更大的百分位数如 95、99 和 99.9(缩写为 p95、p99 和 p999)值，作为典型的响应时间阈值。
采用较高的响应时间百分位数(长尾效应)很重要，因为它们直接影响用户的总体服务体验。例如，亚马逊采用 99.9 百分位数来定义其内部服务的响应时间标准，或许它仅影响 1000 个请求中的 1 个。但是考虑到请求最慢的客户往往是购买了更多的商品，因此数据量更大。换言之，他们是最有价值的客户。
对于后台服务，如果一次完整的服务里包含了多次请求调用，此时高百分位数指标尤为重要。即使这些子请求是并行发送、处理，但最终用户仍然需要等待最慢的那个调用完成才行。
最好将响应时间百分位数添加到服务系统监控中，持续跟踪该指标。例如，设置一个 lOmin 的滑动窗口，监控其中响应时间，滚动计算窗口中的中位数和各种百分位数，然后绘制性能图表。
应对负载增加的方法
我们已经讨论了描述负载的参数以及衡最性能的相关指标，接下来讨论可扩展性：即当负载参数增加时，应如何保持良好性能。
现在谈论更多的是如何在垂直扩展(即升级到更强大的机器)和水平扩展(即将负载分布到多个更小的机器)之间做取舍。
在多台机器上分配负载也被称为无共享体系结构。在单台机器上运行的系统通常更简单，然而高端机器可能非常昂贵，且扩展水平有限，最终往往还是无法避免需要水平扩展。
实际上，好的架构通常要做些实际取舍。例如，使用几个强悍的服务器仍可以比大量的小型虚拟机来得更简单、便宜。
某些系统具有弹性特征，它可以自动检测负载增加，然后自动添加更多计算资源，而其他系统则是手动扩展。
可维护性
软件的大部分成本并不在最初的开发阶段，而是在于整个生命周期内持续的投入，这包括维护与缺陷修复。
不幸的是，许多从业人根本不喜欢维护这些所谓的遗留系统，为此，我们可以在软件设计时开始考虑，尽可能较少维护期间的麻烦，避免造出容易过期的系统。我们将特别关注软件系统的三个设计原则:
- 可运维性
- 简单性
- 可演化性
复杂性有各种各样的表现方式: 状态空间的膨胀、模块紧耦合、令入纠结的相互依赖关系、不一致的命名和术语、为了性能而采取的特殊处理、为解决某特定问题而引入的特殊框架等。
复杂性使得维护变得越来越困难，最终会导致预算超支和开发进度滞后。最终开发人员更加难以准确理解、评估或者更加容易忽略相关行为。
消除意外复杂性最好手段之一是抽象。一个好的设计抽象可以隐藏大量的实现细节，并对外提供干净、易懂的接口。一个好的设计抽象可用于各种不同的应用程序。
一成不变的系统需求几乎没有，想法和目标经常在不断变化: 适配新的外部环境、新的用例、业务优先级的变化、用户要求的新功能、新平台取代旧平台、业务增长促使架构的演变等。
总结
知易行难，我们都知道应该使应用程序可靠、可扩展或可维护，但实际实现他们却并不容易。考虑到一些重要的模式和技术在很多不同应用中普遍适用，在接下来的几章中，我们就一些数据密集系统例子，分析它们如何实现上述这些目标。