1.1 数据系统思想

我们普遍认为数据库、队列、缓存等等，是不同类别的工具。即使数据库和消息队列有一些表面上的相似性----都存储数据，它们有不同的访问模式，也就意味着不同的性能特点，从而有不同的实施方式。

那么我们为什么要把他们全部混在一起在一个涵盖性术语下？比如数据系统。

近几年出现了许多数据存储与处理的新工具。它们针对各种各样的用例做了优化，然后就不再恰好适用于传统的类别。例如，出现了同样适用消息队列的数据库（Redis），也出现了像数据库一样有耐用性保证的消息队列（Apache Kafka）。不同类别间的边界正在变得模糊。

其次，越来越多的应用有如此苛刻或广泛的需求，以至于单个工具不能满足数据处理与存储的要求。作为替代，那些工作被分解为可以在单个工具上高效执行的任务，不同的工具使用应用代码结合到一起。

例如，如果你有一个应用管理的缓存层（使用内存缓存或类似），或者一个与主数据库独立的全文搜索服务器，通常应用代码要负责保持缓存或索引与主数据库同步。图1-1给出了一个简单的例子。

图1-1 数据系统合并若干组件的一种架构

当你为了提供一个服务而合并多个工具时，服务接口或API会将实施细节隐藏。现在你必须根据更小的通用组件创建一个有特定目的的新数据系统。你的复合数据系统可能要提供一定的保障，缓存会被纠正或更新以便外部客户端看到的是一致的结果。你现在不仅是应用开发者，也是一个数据系统设计者。

有许多因素会影响数据系统的设计，包括团队的技能和经验、遗留的系统依赖性、交付的时间尺度、你组织对不同风险的容忍度、监管约束等等。这些因素很大程度上取决于形势。

本书关注的大多数软件系统中都比较重要的三个点：

• 可靠性。系统应该能持续正常的工作（在期望的性能水平上执行正确的功能），即使遇到困难（硬件或软件故障，甚至是人为故障）
• 可扩展性。随着系统的增长（数据量、传输量，或复杂性），应该有合理的处理方法。
• 可维护性。随着时间的流逝，许多不同的人会在系统上工作（构造或操作，维持当前的行为和使系统适应新的用例），他们应该都能高效的使用系统。