当今许多新型利用都属于数据密集型（data-intensive)，而不是计算密集型(compute-intensive)。对于这些类型利用，CPU 的解决能力往往不是第一限制性因素，关键在于数据量、数据的复杂度及数据的疾速多变性。
数据密集型利用通常也是基于规范模块构建而成，每个模块负责繁多的罕用性能。例如，许多利用零碎都蕴含以下模块:
- 数据库: 用以存储数据，这样之后利用能够再次拜访。
- 缓存: 缓存那些简单或操作代价低廉的后果，以放慢下一次拜访。
- 索引: 用户能够按关键字搜寻数据并反对各种过滤。
- 流式解决: 继续发送音讯至另一个过程，解决采纳异步形式。
- 批处理: 定期解决大量的累积数据。
数据系统
咱们通常将数据库、队列、缓存等视为不同类型的零碎。尽管数据库和音讯队列存在某些相似性，例如两者都会保留数据（至多一段时间)，但他们却有着截然不同的拜访模式，这就意味着不同的性能特色和设计实现。
假设某个利用蕴含缓存层（例如 Memcached)与全文索引服务器（如 Elasticsearch 或 Solr)，二者与主数据库放弃关联，通常由利用代码负责缓存、索引与主数据库之间的同步，如图所示。
在下面例子中，组合应用了多个组件来提供服务，而对外提供服务的界面或者 API 会暗藏很多外部实现细节。这样基本上咱们基于一个个较小的、通用的组件，构建而成一个全新的、专用的数据系统。这样的集成数据系统会提供某些技术保障，例如，缓存要正确刷新以保障内部客户端看到统一的后果。
设计数据系统时，会碰到很多辣手的问题。这里将专一与对大多数软件系统都极为重要的三个问题：
- 可靠性(Reliability)：当出现意外状况如硬件、软件故障、人为失误等，零碎应能够持续失常运行：尽管性能可能有所升高，但确保性能正确。
- 可扩展性(Scalability)：随着规模的增长，例如数据量、流量或复杂性，零碎应以正当的形式来匹配这种增长。
- 可维护性（Maintainability)：随着工夫的推移，许多新的人员参加到零碎开发和运维，以保护现有性能或适配新场景等，零碎都应高效运行。
可靠性
对于软件，典型的冀望包含:
- 应用程序执行用户所冀望的性能。
- 能够容忍用户呈现谬误或者不正确的软件应用办法。
- 性能能够应答典型场景、正当负载压力和数据量。
- 零碎可避免任何未经受权的拜访和滥用。
如果所有上述指标都要反对才算“失常工作”，那么咱们能够认为可靠性大抵意味着: 即便产生了某些谬误，零碎仍能够持续失常工作。
硬件故障
当咱们思考系统故障时，对于硬件故障总是很容易想到：硬盘解体，内存故障，电网停电，甚至有人误拔掉了网线。当有很多机器时，这类事件迟早会产生。
咱们的第一个反馈通常是 为硬件增加冗余来缩小零碎故障率。例如对磁盘配置 RAID，服务器装备双电源，甚至热插拔 CPU，数据中心增加备用电源、发电机等。当一个组件产生故障，冗余组件能够疾速接管，之后再更换生效的组件。这种办法能并不能齐全避免硬件故障所引发的生效，但还是被广泛采纳，且在理论中也的确以让零碎不间断运行长达数年。
直到最近，采纳硬件冗余计划对于大多数利用场景还是足够的，它使得单台机器齐全生效的概率降为非常低的程度。只有能够将备份迅速复原到新机器上，故障的停机工夫在大多数利用中并不是灾难性的。而多机冗余则只对大量的要害利用更有意义，对于这些利用，高可用性是相对必要的。
通过软件容错的形式来容忍多机生效也逐步成为新的伎俩，或者至多成为硬件容错的无力补充。这样的零碎更具备操作便利性，例如当须要重启计算机时为操作系统打安全补丁，能够每次给一个节点打补丁而后重启，而不须要同时下线整个零碎。
软件谬误
导致软件故障的 bug 通常会长工夫处于引而不发的状态，直到碰到特定的触发条件。这也意味着系统软件其实对应用环境存在某种假如，而这种假如少数状况都能够满足，然而在特定状况下，假如条件变得不再成立。
软件系统问题有时没有疾速解决办法，而只能认真思考很多细节，包含认真查看依赖的假如条件与零碎之间交互，进行全面的测试，过程隔离，容许过程解体并主动重启，重复评估，监控并剖析生产环节的行为表现等。如果零碎提供某些保障，例如，在音讯队列中，输入音讯的数量应等于输出音讯的数量，则能够一直地查看确认，发现差别则立刻告警。
人为失误
如果咱们假设人是不牢靠的，那么该如何保证系统的可靠性呢？能够尝试联合以下多种办法:
- 以最小出错的形式来设计零碎。例如，精心设计的形象层、API 以及治理界面，使“做正确的事件”很轻松，但搞坏很简单。然而，如果限度过多，人们就会想法来绕过它，这会对消其侧面作用。因而解决之道在于很好的均衡。
- 想方法拆散最容易出错的中央、容易引发故障的接口。特地是，提供一个功能齐全但非生产用的沙箱环境，使人们能够释怀的尝试、体验，包含导入实在的数据，万一呈现问题，不会影响实在用户。
- 充沛的测试：从各单元测试到全系统集成测试以及手动测试。自动化测试已被宽泛应用，对于笼罩失常操作中很少呈现的边界条件等尤为重要。
- 当呈现人为失误时，提供疾速的复原机制以尽量减少故障影响。例如，疾速回滚配置改变，滚动公布新代码（这样任何意外的谬误仅会影响一小部分用户），并提供校验数据的工具（避免旧的计算形式不正确）。
- 设置具体而清晰的监控子系统，包含性能指标和错误率。监控能够向咱们发送告警信号，并查看是否存在假如不成立或违反约束条件等。这些检测指标对于诊断问题也十分有用。
- 推广治理流程并加以培训。
可扩展性
可扩展性是用来形容零碎应答负载减少能力的术语。然而请留神，它并不是掂量一个零碎的一维指标，议论“X 是可扩大”或“Y 不扩大”没有太大意义。相同，探讨可扩展性通常要思考这类问题:“如果零碎以某种形式增长，咱们应答增长的措施有哪些”，“咱们该如何增加计算资源来解决额定的负载”。
形容负载
首先，咱们须要简洁地形容零碎以后的负载，只有这样能力更好地探讨后续增长问题(例如负载加倍会意味着什么)。负载能够用称为负载参数的若干数字来形容。参数的最佳抉择取决于零碎的体系结构，它可能是 Web 服务器的每秒申请解决次数，数据库中写入的比例，聊天室的同时流动用户数量，缓存命中率等。有时平均值很重要，有时零碎瓶颈来自于多数峰值。
以 Twitter 为例，Twitter 的两个典型业务操作是:
- 公布 tweet 音讯：用户能够疾速推送新音讯到所有的关注者，均匀大概 4.6k request/sec，峰值约 12k requests/sec。
- 主页工夫线 (Home timeline) 浏览：均匀 300k request/sec 查看关注对象的最新消息。
仅仅解决峰值约 12k 的音讯发送听起来并不难，然而，Twitter 扩展性的挑战重点不于音讯大小，而在于微小的扇出 (fan-out)构造：每个用户会关注很多人，也会被很多人圈粉。此时大略有两种解决计划:
1. 将发送的新 tweet 插入到全局的 tweet 汇合中。当用户查看工夫线时，首先查找所
有的关注对象，列出这些人的所有 tweet，最初以工夫为序来排序合并。如果以下图的关系型数据模型，能够执行下述的 SQL 查问语句:
SELECT tweets.*,users.* FROM tweets
JOIN users ON tweets.sender_id = users.id
JOIN follows ON follows.followee_id = users.id
WHERE follows.follower_id = current_user
2. 对每个用户的工夫线保护一个缓存，如图所示，相似每个用户一个 tweet 邮
箱。当用户推送新 tweet 时，查问其关注者，将 tweet 插入到每个关注者的工夫线缓存中。因为曾经事后将后果取出，之后拜访工夫线性能十分快。
Twitter 在其第一个版本应用了办法 1，但发现主页工夫线的读负载压力一劳永逸，系统优化颇费周折，因而转而采纳第二种办法。实际发现这样更好，因为工夫线浏览 tweet 的压力简直比公布 tweet 要高出两个数量级，基于此，在公布时多实现一些事件能够减速读性能。
然而，办法 2 的毛病也很显著，在公布 tweet 时减少了大量额定的工作。思考均匀 75 个关注者和每秒 4.6k 的 tweet，则须要每秒 4.6 × 75 = 345k 速率写入缓存。然而，75 这个均匀关注者背地还暗藏其余事实，即关注者其实偏差微小，例如某些用户领有超过 3000 万的追随者。这就意味着峰值状况下一个 tweet 会导致 3000 万笔写入！而且要求尽量快，Twitter 的设计指标是 5s 内实现，这成为一个微小的挑战。
在 Twitter 的例子中，每个用户关注者的散布状况（还能够联合用户应用 Twitter 频率状况进行加权）是该案例可扩大的要害负载参数，因为它决定了扇出数。其余利用可能具备不同的个性，但能够采纳相似的准则来钻研具体负载。
Twitter 故事最初的终局是：办法 2 曾经失去了稳固实现，Twitter 正在转向联合两种办法。大多数用户的 tweet 在公布时持续以一对多写入工夫线，然而多数具备超多关注者 (例如那些名人) 的用户除外，对这些用户采纳相似计划 1，其推文被独自提取，在读取时才和用户的工夫线主表合并。这种混合办法可能提供始终如一的良好体现。
形容性能
形容零碎负载之后，接下来构想如果负载减少将会产生什么。有两种思考形式：
- 负载减少，但系统资源（如 CPU、内存、网络带宽等）放弃不变，零碎性能会产生什么变动？
- 负载减少，如果要放弃性能不变，须要减少多少资源？
这两个问题都会关注性能指标，所以咱们先简要介绍一下如何形容零碎性能。
在批处理零碎如 Hadoop 中，咱们通常关怀吞吐量(throughput)，即每秒可解决的记录条数，或者在某指定数据集上运行作业所需的总工夫；而在线零碎通常更看重服务的响应工夫(response time)，即客户端从发送申请到接管响应之间的距离。
咱们常常考查的是服务申请的均匀响应工夫。然而，如果想晓得更典型的响应工夫，平均值并不是适合的指标，因为它覆盖了一些信息，无奈通知有多少用户理论经验了多少提早。
因而 最好应用百分位数 （percentiles)。如果曾经收集到了响应工夫信息，将其从最快到最慢排序，中位数（median) 就是列表两头的响应工夫。例如，如果中位数响应工夫为 200 ms，那意味着有一半的申请响应不到 200 ms，而另一半申请则须要更长的工夫。
为了弄清楚异样值有多蹩脚，须要关注更大的百分位数如常见的第 95、99 和 99.9(缩写为 p95、p99 和 p999）值。作为典型的响应工夫阈值，它们别离示意有 95%、99% 或 99.9% 的申请响应工夫快于阈值。例如，如果 95 百分位数响应工夫为 1.5s，这意味着 100 个申请中的 95 个申请快于 1.5s，而 5 个申请则须要 1.5s 或更长时间。
采纳较高的响应工夫百分位数 (tail latencies，尾部提早或长尾效应）很重要，因为它们间接影响用户的总体服务体验。 例如，亚马逊采纳 99.9 百分位数来定义其外部服务的响应工夫规范，或者它仅影响 1000 个申请中的 1 个。然而思考到申请最慢的客户往往是购买了更多的商品，因而数据量更大换言之，他们是最有价值的客户。让这些客户始终保持愉悦的购物体验显然十分重要：亚马逊还留神到，响应工夫每减少 100ms，销售额就会降落了约 1%，其余钻研则表明，1s 的提早减少等价于客户满意度降落 16%。
排队提早往往在高百分数响应工夫中影响很大。因为服务器并行处理的申请无限（例如，CPU 内核数的限度)，正在解决的多数申请可能会阻挡后续申请，这种状况有时被称为队头阻塞。即便后续申请可能解决很简略，但它阻塞在期待先前申请的实现，客户端将会察看到极慢的响应工夫。因而，很重要的一点是要在客户端来测量响应工夫。
因而，当测试零碎可扩展性而人为产生负载时，负载生成端要独立于响应工夫来继续发送申请。如果客户端在发送申请之前总是期待先前申请的实现，就会在测试中人为地缩短了服务器端的累计队列深度，这就带来了测试偏差。
应答负载减少的办法
当初议论更多的是如何在垂直扩大（即降级到更弱小的机器）和程度扩大（行将负载散布到多个更小的机器）之间做取舍。在多台机器上调配负载也被称为无共享体系结构。在单台机器上运行的零碎通常更简略，然而高端机器可能十分低廉，且扩大程度无限，最终往往还是无奈防止须要程度扩大。实际上，好的架构通常要做些理论取舍，例如，应用几个强悍的服务器仍能够比大量的小型虚拟机来得更简略、便宜。
某些零碎具备弹性特色，它能够自动检测负载减少，而后主动增加更多计算资源，而其余零碎则是手动扩大（人工剖析性能体现，之后决定增加更多计算)。如果负载高度不可预测，则主动弹性零碎会更加高效，但或者手动形式能够缩小执行期间的意外状况。
把无状态服务散布而后扩大至多台机器绝对比拟容易，而有状态服务从单个节点扩大到分布式多机环境的复杂性会大大增加。出于这个起因，直到最近通常的做法始终是，将数据库运行在一个节点上（采纳垂直扩大策略），直到高扩展性或高可用性的要求迫使不得不做程度扩大。
然而，随着相干分布式系统专门组件和编程接口越来越好，至多对于某些利用类型来讲，上述通常做法或者会产生扭转。能够乐观构想，即便利用可能并不会解决大量数据或流量，但将来分布式数据系统将成为标配。
对于特定利用来说，扩大能力好的架构通常会做出某些假如，而后有针对性地优化设计，如哪些操作是最频繁的，哪些负载是多数状况。如果这些假如最终发现是谬误的，那么可扩展性的致力就徒劳了，甚至会呈现与设计预期齐全相同的状况。对于晚期的初创公司或者尚未定型的产品，疾速迭代推出产品性能往往比投入精力来应答不可知的扩展性更为重要。
可维护性
从软件设计时就应该开始思考，尽可能较少保护期间的麻烦，至防止造出容易过期的零碎。为此，咱们将特地关注软件系统的三个设计准则:
- 可运维性：不便经营团队来放弃零碎安稳运行。
- 简略性：简化零碎复杂性，使新工程师可能轻松了解零碎。留神这与用户界面的简略性并不一样。
- 可演变性：后续工程师可能轻松地对系统进行改良，并依据需要变动将其适配到非典型场景，也称为可延伸性、易批改性或可塑性。
可运维性
良好的可运维性意味着使日常工作变得简略，数据系统设计能够在这方面奉献很多，包含:
- 提供对系统运行时行为和外部的可观测性，不便监控。
- 反对自动化，与规范工具集成。
- 防止绑定特定的机器，这样在整个零碎不间断运行的同时，容许机器停机保护。
- 提供良好的文档和易于了解的操作模式，诸如“如果我做了 X，会产生 Y”。
- 提供良好的默认配置，且容许管理员在须要时不便地批改默认值。
- 尝试自我修复，在须要时让管理员手动控制系统状态。
- 行为可预测，缩小意外产生。
简略性
小型软件我的项目通常能够写出简略而丑陋的代码，但随着我的项目越来越大，就会越来越简单和难以了解。这种复杂性拖慢了开发效率，减少了保护老本。
复杂性有各种各样的体现形式：状态空间的收缩，模块紧耦合，令人纠结的相互依赖关系，不统一的命名和术语，为了性能而采取的非凡解决，为解决某特定问题而引入的非凡框架等。
打消意外复杂性最好伎俩之一是形象。一个好的设计形象能够暗藏大量的实现细节，并对外提供洁净、易懂的接口。一个好的设计形象可用于各种不同的应用程序。这样，复用远比多次重复实现更有效率；另一方面，也带来更高质量的软件，而品质过硬的形象组件所带来的益处，能够使运行其上的所有利用轻松获益。
可演变性
变化无穷的零碎需要简直没有，想法和指标常常在一直变动：适配新的外部环境，新的用例，业务优先级的变动，用户要求的新性能，新平台取代旧平台，法律或监管要求的变动，业务增长促使架构的演变等。
在组织流程方面，麻利开发模式为适应变动提供了很好的参考。麻利社区还公布了很多技术工具和模式，以帮忙在频繁变动的环境中开发软件，例如测试驱动开发（TDD）和重构。
咱们的指标是能够轻松地批改数据系统，使其适应一直变动的需要，这和简略性与抽象性密切相关：简略易懂的零碎往往比简单的零碎更容易批改。这是一个十分重要的理念，咱们将采纳另一个不同的词来指代数据系统级的敏捷性，即可演变性。