我们通常把数据库，队列，缓存等看作是非常不同的工具类别。尽管数据库和消息队列有一些表面上的相似之处----它们都是在一段时间内存储数据，但它们的访问模式不同，这也意味着不同的性能特征和不同的实现方式。
那么，为什么我们要把它们都放在一个像数据系统这样的保护伞下呢？
近年来出现了许多用于数据存储和数据处理的新工具。它们针对各种不同的用例进行了优化，它们不在适合传统的分类。例如，有一些数据存储也被用作消息队列（redis），还有一些消息队列具有与数据库类似的持久性保证（kafka）。这些分类之间的界限正在变得模糊。
其次，越来越多的应用程序现在都有非常广泛的需求，以至于单个工具已经不能满足所有数据处理和数据存储的需求。相反，这些工作被分解为可以在单个工具上高效执行的任务，并通过应用程序代码把这些工具串联到一起。
例如，如果您有一个应用程序管理的缓存层（使用memcached或者类似应用），或者一个与主数据分开的全文搜索服务器（比如Elasticsearch或者Solr），通常是应用程序代码负责将这些缓存和索引与主数据库保持通过。我们可以用个图1-1大致了解它的样子（后面的章节将详细介绍）。
图1-1.数据系统的一个可能的架构，它包含了多个组件
当您结合几个工具来提供服务时，服务的接口或者应用程序的编程接口（API）通常会将这些实现细节从客户端隐藏起来。现在，您已经通过一些较小的通用组件创建了一个新的，专用的数据系统。您的复合数据系统需要提供某些保证：例如，缓存将正确地失效或者更新，以便让外部客户端看到一致的结果。你现在不仅仅是一个应用程序的开发人员，而且还是一个数据系统的设计人员。
如果您正在设计一个数据系统或者服务，那么就会出现许多棘手的问题。如何确保数据的正确性和完整性，即使在内部发生错误的情况下。如何为客户端提供持续良好的性能，即使系统的某些部分已经退化了。如何进行扩展以应对负载的增加。对于服务来说，一个好的API是什么样子的呢？
有许多因素可能影响数据系统的设计，包括相关人员的技能和经验，遗留系统的依赖性、交付时间，公司对不同风险的容忍程度、监管约束等等。这些因素很大程度上取决于当时的形势。
在本书中，我们主要关注三个大多数软件系统中很重要的问题：
可靠性---即使在面对逆境（硬件或者软件故障，甚至是人为错误）的情况下，系统也应该继续正确的工作（在期望的性能水平上执行正确的功能）。
可扩展性---随着系统的增长（在数据量、流量或者复杂性方面），应该有合理的方式来处理这种增长。
可维护性---随着时间的推移，许多不同的人将在系统上工作（工程和操作，维护当前的行为并系统适应新的用例），并且他们都应该能够有效的进行工作。
这些词经常在没有清楚地理解它们意思的情况下出现。出于对工程的深思熟虑，我们将在本章其余部分探索关于可靠性、可扩展性和可维护性的思考方式。然后在接下来的章节中，我们将研究用于实现这些目标的各种技术、架构和算法。
网友评论