读书笔记|可靠性，可扩展性，可维护性

《数据密集型应用系统设计》把所有跟 数据 有关的知识点做了剖析、整理、总结，从一个很高的层次把各项技术的共性和区别讲得透彻。

这本书分为了三部分：

第一部分：数据系统的基石，包括数据模型与查询语言、存储与检索、数据编码与演化；

第二部分：分布式数据，包括复制、分片、事务、一致性与共识；

第三部分：衍生数据，包括批处理、流处理、数据系统的未来。

当我们理解技术的底层原理之后，就能明白每项技术产生的背景是什么，解决了什么问题，有什么适用场景。

后面我会把阅读《数据密集型应用系统设计》的读书笔记记录下来，当做自己的总结。

关于数据系统的思考

1. 许多新的数据存储工具与数据处理工具，针对不同应用场景进行优化，因此不再适合生硬地归入传统类别。类别之间的界限变得越来越模糊，例如：数据存储可以被当成消息队列用（Redis），消息队列则带有类似数据库的持久保证（Apache Kafka）。
2. 单个工具已经不能满足应用系统的需求，总体工作被拆分成一系列能被单个工具高效完成的任务，并通过应用代码将它们缝合起来。 比如，将缓存（应用管理的缓存层，Memcached或同类产品）和全文搜索（全文搜索服务器，例如Elasticsearch或Solr）功能从主数据库剥离出来，那么使缓存/索引与主数据库保持同步通常是应用代码的责任。

数据密集型（data-intensive） VS 计算密集型 （compute-intensive）

一个应用被称为数据密集型的，如果数据是其主要挑战（数据量，数据复杂度、数据变化速度)——与之相对的是计算密集型，即处理器速度是其瓶颈。影响数据系统设计的因素很多，本书着重讨论三个在大多数软件系统中都很重要的问题：

1. 可靠性（Reliability） 系统在困境（adversity）（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。
2. 可扩展性（Scalability） 有合理的办法应对系统的增长（数据量、流量、复杂性）
3. 可维护性（Maintainability） 许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）

可靠性

定义

1. 造成错误的原因叫做故障（fault），能预料并应对故障的系统特性可称为容错（fault-tolerant）或韧性（resilient）
2. 故障（fault）不同于失效（failure）。故障通常定义为系统的一部分状态偏离其标准，而失效则是系统作为一个整体停止向用户提供服务。
3. 尽管比起阻止错误（prevent error），我们通常更倾向于容忍错误。但也有预防胜于治疗的情况（比如不存在治疗方法时）

硬件故障

1. 硬件故障（hardware faults）一旦你拥有很多机器，这些事情总会发生！
2. 为了减少系统的故障率，第一反应通常都是增加单个硬件的冗余度，RAID, UPS,数据中心可能有电池和柴油发电机作为后备电源
3. 云平台的设计就是优先考虑灵活性（flexibility）和弹性（elasticity）i，而不是单机可靠性。(这句话云计算平台从业者并不意外。)

软件错误

1. 这类错误难以预料，而且因为是跨节点相关的，所以比起不相关的硬件故障往往可能造成更多的系统失效 (经常听说 我运行的时候好好的，是不是硬件系统问题)
2. 软件故障的bug 通常潜伏很长时间，直到被异常情况触发为止。往往是某个假设出于某种原因最后不在成立了。
3. 解决办法：仔细考虑系统中的假设和交互；彻底的测试；进程隔离；允许进程崩溃并重启；测量、监控并分析生产环境中的系统行为。

人为错误

1. 设计并构建了软件系统的工程师以及维持系统运行的运维都是人类。即使他们怀有最大的善意，人类也是不可靠的。
2. 解决方法：以最小化犯错机会的方式设计系统；将人们最容易犯错的地方与可能导致失效的地方解耦；测试；更好的 CICD ，发布回滚策略；培训

可扩展性

定义

1. 可扩展性（Scalability）是用来描述系统应对负载增长能力的术语。

描述负载

参数的最佳选择取决于系统架构，它可能是每秒向Web服务器发出的请求、数据库中的读写比率、聊天室中同时活跃的用户数量、缓存命中率或其他东西。除此之外，也许平均情况对你很重要，也许你的瓶颈是少数极端场景。

我们以推特在2012年11月发布的数据为例。推特的两个主要业务是：

发布推文

用户可以向其粉丝发布新消息（平均 4.6k请求/秒，峰值超过 12k请求/秒）。

主页时间线

用户可以查阅他们关注的人发布的推文（300k请求/秒）。推特的发推设计：

1. 发布推文时，只需将新推文插入全局推文集合即可。当一个用户请求自己的主页时间线时，首先查找他关注的所有人，查询这些被关注用户发布的推文并按时间顺序合并。
2. 为每个用户的主页时间线维护一个缓存，就像每个用户的推文收件箱（图1-3）。当一个用户发布推文时，查找所有关注该用户的人，并将新的推文插入到每个主页时间线缓存中。因此读取主页时间线的请求开销很小，因为结果已经提前计算好了。
3. 系统迭代之后， 推特 选择方式 1+ 方式 2 的混合， 其实国内的新浪微博也是类似的架构。

描述性能

1. 当描述好负载以后，问题变成了：a. 增加负载参数并保持系统资源不变时，系统性能将受到什么影响？b. 增加负载参数并希望性能不变时，需要增加多少系统资源？
2. 批处理系统，通常关心吞吐量（throughput）；在线系统，通常更关心响应时间（response time）

1. 对于系统响应时间而言，最好用百分位点，比如中位数、p99 等标识。
2. 测量客户端的响应时间非常重要（而不是服务端），比如会出现头部阻塞、网络延迟等。
3. 实践中的百分位点，可以用一个滑动的时间窗口（比如 10 分钟）进行统计。可以对列表进行排序，效率低的话，考虑一下前向衰减，t-digest 等方法近似计算。

应对负载的方法

1. 纵向扩展：升级系统硬件，更强大的机器
2. 横向扩展：增加机器数量，将负载分布到多台机器上
3. 弹性系统：检测到负载增加时自动增加计算资源
4. 跨多台机器部署无状态服务比较简单，但是把带状态的数据系统从单节点变成分布式配置则可能引入许多额外复杂度。因此，应该尽量将数据库放在单个节点上。(随着云计算的发展，这条当前已经不再适用)

可维护性

1. 在设计之初就尽量考虑尽可能减少维护期间的痛苦，从而避免自己的软件系统变成遗留系统。
2. 三个设计原则：可操作性（Operability）便于运维团队保持系统平稳运行。简单性（Simplicity）从系统中消除尽可能多的复杂度（complexity），使新工程师也能轻松理解系统。（注意这和用户接口的简单性不一样。） 可演化性（evolability）使工程师在未来能轻松地对系统进行更改，当需求变化时为新应用场景做适配。也称为可扩展性（extensibility），可修改性（modifiability）或可塑性（plasticity）。

可操作性：人生苦短，关爱运维

1. 良好的运维经常可以绕开垃圾（或不完整）软件的局限性，而再好的软件摊上垃圾运维也没法可靠运行”
2. 运维系统尽量自动化。

简单性：管理复杂度

1. 消除额外的（accidental）的复杂度
2. 消除额外复杂度的最好工具之一是抽象（abstraction）

可演化性：拥抱变化

1. 敏捷（agile） 工作模式为适应变化提供了一个框架
2. 简单易懂的系统通常比复杂系统更容易修改，即可演化性（evolvability）