Redis 8 来了——而且它是开源的
了解更多
从基础到最佳实践
数据库架构是指数据库系统的设计和结构。数据库的架构决定了组织如何存储、访问、管理和保护数据。
选择错误的架构必然会导致未来的问题，甚至可能需要重建。在本文中，我们将指导您了解基础知识，包括什么是数据库架构及其组成部分，帮助您避免这种命运。我们还将向您展示数据库架构的一些实践要素，包括正常运行时间的重要性以及数据库在微服务中扮演的角色。
数据库架构是指公司及其开发人员如何设置和配置数据库系统，以支持其应用程序、网站和基础设施。
数据库设计决定了完全不同的数据存储、保护、管理和访问方式，因此这是一项需要尽早做出的重要决定——它会对您的系统功能产生持久影响。
数据库架构主要由四个组件组成，但每个组件会根据具体数据库而异。
在复杂的系统中，公司通常会采用多个数据库，这些数据库的组件版本不同，数据管理方法也不同。
例如，公司可能会使用 Snowflake 作为分析数据库来存储分析数据并支持编写冗长复杂的查询；使用 Redis 作为内存数据库来支持快速操作以支持微服务；使用 Kafka 作为流数据库来支持数据的流传输；以及使用一系列生产数据库，例如 MySQL，来存储应用程序数据。
当人们寻找合适的数据库时，他们往往会陷入细微差别中，并把应该问的问题复杂化。
例如，您可能知道合适的数据库需要能够以精细的方式组织数据以实现高效检索，或者合适的数据库需要支持多种查询方式。但是当您开始搜索时，最好先回顾一下，看看基本类型，然后从高层向下过滤到更低、更细致的层次。
在深入细节之前，先确定您需要的数据库架构是关系型还是非关系型，以及它应该是单层、双层还是三层。
选择关系型数据库和非关系型数据库（后者更常被称为 NoSQL）取决于几个主要因素：
每种数据库类型的用法尤其不同，因为在关系型数据库中，您编写 SQL 查询来关联表之间的数据；而在 NoSQL 数据库中，没有表，数据库也不定义或强制执行特定的数据关联方式。
在单层架构中，数据库的所有组件——包括数据本身、用户界面和应用程序逻辑——都驻留在同一台服务器上。
单层架构的数据库在企业环境中很少见。这些数据库更常用于只需小规模运行的应用程序或需要优先考虑节省成本的用户。
在双层架构（也称为客户端-服务器架构）中，数据库被分成两部分。客户端（更常见的是多个客户端）直接连接到数据库所在的服务器，但两者在逻辑和物理上是分离的。
双层架构在现代企业环境中也不常见。过去，当用例像连接桌面应用程序到本地服务器上托管的数据库一样简单时，这些架构很常见。然而，现在，在云、SaaS 和微服务兴起很久之后，双层架构已不再流行。
在三层架构中，数据库被分成三部分。多个客户端连接到后端，后端再连接到数据库。三层架构使用后端作为中介，这具有许多优势，使其成为企业环境中最常见的类型。
例如，企业可以通过确保数据库只连接到单个后端来限制访问并降低安全漏洞的可能性。类似地，通过将这种级别的分离作为首要原则来设计数据库，企业可以确保开发人员可以独立操作各层，从而更容易实现可伸缩性。
如果您正在设计数据库架构，了解键以及它们在不同架构中如何工作的细微差别对于构建支持您需求的数据库至关重要。简而言之，键是数据库识别表内记录并创建表之间链接的方式。
键之所以重要，主要有三个原因：
键有几种不同的类型，包括主键（唯一标识每条记录）、外键（创建表之间的链接）以及复合键（组合单个表中的多个列）。
如今，用户期望的正常运行时间水平只能用多个小数点来描述（“高可用性”或 99.999% 的正常运行时间）。尽管软件变得更加复杂和相互依赖，但希望维持用户信任的公司必须在最早的数据库决策中就纳入正常运行时间和可用性方面的考量。
您很快就会在寻找数据库选项时听到有关CAP 定理的信息。CAP 是 Consistency（一致性）、Availability（可用性）和 Partition tolerance（分区容错性）的首字母缩写。这个理论表面上很简单，但深入研究后会变得复杂。
简而言之，CAP 定理是一个经典的“三选二”问题：一个分布式系统不可能同时满足一致性、可用性和分区容错性。
这里，一致性意味着写操作完成后开始的读操作必须返回该值；可用性意味着系统中的节点接收到的每个请求都必须产生响应；而分区容错性意味着允许网络丢失从一个节点发送到另一个节点的消息。
Eric Brewer，现任 Google 基础设施副总裁、加州大学伯克利分校计算机科学名誉教授，在 2000 年提出了最初的定理并进行了展示。即使几十年后，这个定理对于思考数据库需求的人们来说仍然是一个重要的立足点。
这三者中的每一个选择都带来了权衡，构建数据库的公司需要接受无法同时拥有这三者的残酷现实。
对于大多数公司来说，可用性——缺乏它会导致停机——是定理中成本过高而无法降低优先级的那个部分。
例如，Splunk 研究表明，全球 2000 强公司每年因停机和服务降级损失 4000 亿美元。诸如 Meta 和 Amazon 等大公司也面临这个问题，它们在停机事件中分别损失了 1 亿美元的收入和 3400 万美元的销售额。
企业投入大量精力和资金来扩展规模，但如果其基础设施和支持它们的数据库无法处理这种规模，那么增加的客户覆盖范围可能会变成增加的客户失望。早期公司通常具有更大的灵活性，但对于已成为众多企业和用户必备工具的企业来说，需要优先考虑可用性以维持客户依赖的信任。
数据库可用性的关键难题在于如何确保数据库有足够的资源来完成请求，以及在任何时刻都有足够的资源来快速完成新的请求。
随着新用户和请求的涌入，数据库有两种选择：纵向或横向扩展。简而言之，纵向扩展意味着企业使其服务器更大或更快。横向扩展意味着企业将相关数据库分布在多个较小的服务器上。
这里没有“最佳方式”，因为每个方向都存在权衡。其中有一些细微差别，但 Technically 时事通讯的作者 Justin Gage 将权衡总结如下：“纵向扩展很容易，但横向扩展效率更高。”
(来源)
从一台服务器切换到更大、更快的一台相对容易，但您也会不可避免地遇到限制。添加新的服务器可以绕过这些限制，但每增加一台服务器都会增加复杂性和协调成本。例如，如果您正在横向扩展数据库，修补、流量分配和服务器同步都会成为棘手的问题。
对于超大型数据库，可伸缩性变得更加困难。Redis Cloud 使用集群将数据库数据分发到不同的云实例来解决这个问题。如果数据超出单个服务器 RAM 的能力，性能会下降，但通过集群，大量的数据库分片（独立数据库服务器实例中的分区）分摊了负载。
Redis 通过复制解决了同样的挑战，它为 Redis 实例添加了“主从”模式。在这种模式下，复制的 Redis 实例始终是主实例的精确副本，确保无论主实例发生什么，都会有一个精确的副本准备就绪。
API（即应用程序编程接口）驱动着现代互联网。
API 可以很小，例如在微服务环境中连接公司组件的内部协议，也可以很大，是定义公司的协议。例如，Stripe 和 Twilio 通过 API 提供其主要产品（分别是支付处理和通信服务），允许用户编写几行代码，调用 API，并访问世界一流的功能。
然而，正是这些使 API 引人入胜的功能，如果它们无法扩展，也会使它们变得脆弱。
正确的数据库和正确的数据库架构对于实现 API 所需的可伸缩性至关重要。通过了解 Redis 作为内存数据库为 API 开发人员提供了什么，您可以看到数据库架构决策有多么重要。
无论您的最终用户是依赖 API 返回数据的非技术消费者，还是依赖内部 API 来确保其系统保持高性能的专业用户，可伸缩性都是一项要求。
上述三个风险结合起来，形成了最大的风险：糟糕的用户体验。用户期望持续稳定的服务，延迟和停机不仅会导致挫败感，甚至可能导致完全放弃使用该服务。
即使对于像开发人员这样的专业用户来说，他们可能不具备轻易切换应用程序的能力，但糟糕的性能也会导致糟糕的开发者体验，其后果远不止是单纯的烦恼。例如，近期一项Atlassian 研究显示，97% 的开发人员因效率低下而损失大量时间。
因此，大多数开发人员因为糟糕的开发者体验而考虑离开他们工作的公司。
Redis 是一种内存数据库，企业可以使用它来减轻主数据库的负载。通过 Redis，企业可以缓存会话数据，从而使请求不会被路由到生产数据库，这是生产数据库最常被压垮的原因之一。
此能力在微服务环境中特别有用。微服务架构将单体应用拆分成一系列通过 API 连接的服务，其运行依赖于这些 API 的可伸缩性。如果没有可靠的 API，原本功能正常的微服务网络可能会变成一排倒下的多米诺骨牌。使用 Redis，团队可以缓存常见的 API 调用，从而加速整个系统——在不牺牲性能的情况下提高可伸缩性。
Redis 在构建数据系统的公司中是一个受欢迎的选择，因为它检索值速度快，易于使用，并且对多种常见数据模型具有灵活性。
与其他倾向于将数据存储在磁盘上的数据库不同，Redis 将数据存储在 RAM 中（或内存中）。因此，亚马逊技术负责人 Animesh Gaitonde 写道：“从内存中获取数据的速度比从磁盘中获取数据快几个数量级。”他继续说道，Redis 无需使用耗时的 I/O 调用，“能够绕过 I/O 调用并直接从内存中提供数据。”
(来源)
当应用程序需要存储和查询大量的用户会话数据时，这种速度特别有用——这也是许多数据系统使用 Redis 的另一个原因。应用程序经常使用会话存储来跟踪用户身份、购物车商品、个性化信息等。Redis Enterprise 提供的会话存储支持满足依赖用户会话数据的应用程序所需规模、速度和持久性。
许多技术选项需要在速度和灵活性之间进行权衡，要求用户在适用于多种场景但速度较慢的解决方案或适用于单一场景但速度较快的解决方案之间进行选择。然而，Redis 自 2009 年诞生以来得到数十年的开源开发支持，支持多种数据模型，包括 key:value、hash、JSON、sets、sorted sets、strings 和流数据。
测试 Redis 数据库功能的最佳方法是设置并开始使用它。Redis 提供了许多快速入门指南来帮助您开始，无论您是想构建数据结构存储、文档数据库还是向量数据库。
拥有 Redis 账户后，您可以通过几种方式连接到 Redis 服务器，例如连接到在 localhost (-h 127.0.0.1) 上运行并监听默认端口 (-p 6379) 的 Redis 服务器。
然后，您可以在 Redis 中使用与本地环境中相同的数据类型。Redis 字符串存储字节序列（例如文本和二进制数组），您可以轻松获取字符串值。
如前所述，Redis 中的每个项目都有一个唯一的键，每个键都位于 Redis 键空间中。在下面的示例中，您可以使用简单的 SCAN 命令扫描 Redis 键空间。
最初的构建块很简单，但您使用 Redis 构建的数据库系统足够复杂，可以处理各种各样的用例。要了解更多信息，请预约与 Redis 专家会面。
当您在设计精良的建筑中工作或生活时，您不会过多地考虑建筑架构。即使您在精心建造的公寓庭院里享受室外空气的流入，或是在设计良好的办公楼里享受协作的便利，您也可能不会停下来欣赏支持这些体验的建筑设计。
这是有充分理由的：设计良好的建筑会融入背景，让您做您需要做的事情。当建筑出现问题——通过阻碍您的方式来宣告其糟糕的设计时——您更有可能想到它。
数据库架构也是如此。正确的数据库架构可以减少摩擦，让您专注于产品开发和交付。同时，它也为您提供增长和实验所需的必要支持，确保您可以运营核心业务并同时考虑增长。
相比之下，错误的数据库架构可能会施加限制——通常比您预期的要早——并使产品开发难以获得动力。最终，摩擦可能会占主导地位，您可能需要完全替换数据库，这可能代价高昂。
相反，从一开始就要仔细权衡您的选择，考虑您的用例，并选择一个既能满足您当前需求又能承诺未来随您扩展的数据库。
