数据分区策略

本文介绍在各种 Azure 数据存储中对数据进行分区的一些策略。 有关何时对数据和最佳做法进行分区的一般指南，请参阅 数据分区。

对 Azure SQL 数据库进行分区

单个 SQL 数据库对可以包含的数据量有限制。 吞吐量受体系结构因素及其支持的并发连接数的约束。

弹性池 支持 SQL 数据库的水平缩放。 使用弹性池，可以将数据分区为分布在多个 SQL 数据库的分片中。 还可以添加或删除分片，因为需要处理增长和收缩的数据量。 弹性池还可以通过跨数据库分配负载来帮助减少争用。

每个分片都作为 SQL 数据库实现。 分片可以容纳多个数据集（称为 shardlet）。 每个数据库维护描述其包含的 shardlet 的元数据。 shardlet 可以是单个数据项，也可以是共享同一 shardlet 键的一组项。 例如，在多租户应用程序中，shardlet 密钥可以是租户 ID，租户的所有数据都可以保存在同一 shardlet 中。

客户端应用程序负责将数据集与 shardlet 密钥相关联。 单独的 SQL 数据库充当全局分片映射管理器。 此数据库包含系统中所有分片和 shardlet 的列表。 应用程序连接到分片映射管理器数据库以获取分片映射的副本。 它在本地缓存分片映射，并使用映射将数据请求路由到相应的分片。 此功能隐藏在 弹性数据库客户端库中包含的一系列 API 后面，该库适用于 Java 和 .NET。

有关弹性池的详细信息，请参阅 使用 Azure SQL 数据库横向扩展。

若要降低延迟并提高可用性，可以复制全局分片映射管理器数据库。 使用高级定价层，可以配置活动异地复制，以持续将数据复制到不同区域中的数据库。

或者，使用 Azure SQL 数据同步 或 Azure 数据工厂 跨区域复制分片映射管理器数据库。 这种形式的复制会定期运行，如果分片映射不常更改，并且不需要高级层，则更合适。

弹性数据库提供了两种方案，用于将数据映射到 shardlet 并将其存储在分片中：

• 列表分片映射 将单个键关联到 shardlet。 例如，在多租户系统中，每个租户的数据可以与唯一密钥相关联，并存储在其自己的 shardlet 中。 为了保证隔离，每个 shardlet 可以保存在其自己的分片中。

  

  下载此图的 Visio 文件。

• 范围分片映射 将一组连续键值关联到 shardlet。 例如，可以将一组租户（每个租户都有自己的密钥）的数据分组到同一 shardlet 中。 此方案的成本低于第一个方案，因为租户共享数据存储，但隔离程度较低。

  

  下载此关系图的 Visio 文件

单个分片可以包含多个 shardlet 的数据。 例如，可以使用列表 shardlet 在同一分片中存储不同非连续租户的数据。 还可以在同一分片中混合范围 shardlet 和列出 shardlet，尽管它们将通过不同的映射进行寻址。 下图显示了此方法：

下载此图的 Visio 文件。

弹性池可以添加和删除分片，因为数据量收缩和增长。 客户端应用程序可以动态创建和删除分片，并以透明方式更新分片映射管理器。 但是，删除分片是一项破坏性作，还需要删除该分片中的所有数据。

如果应用程序需要将分片拆分为两个单独的分片或合并分片，请使用 拆分/合并工具。 此工具作为 Azure Web 服务运行，并在分片之间安全地迁移数据。

分区方案可能会显著影响系统的性能。 它还会影响必须添加或删除分片的速率，或者必须跨分片重新分区数据。 请考虑以下几点：

• 将同一分片中一起使用的数据分组，并避免访问多个分片中的数据的作。 分片是自己的 SQL 数据库，必须在客户端执行跨数据库联接。

  尽管 SQL 数据库不支持跨数据库联接，但可以使用弹性数据库工具来执行 多分片查询。 多分片查询将单个查询发送到每个数据库并合并结果。

• 不要设计一个在分片之间具有依赖关系的系统。 一个数据库中的引用完整性约束、触发器和存储过程不能引用另一个数据库中的对象。

• 如果查询经常使用引用数据，请考虑跨分片复制此数据。 此方法可以消除跨数据库联接数据的需求。 理想情况下，此类数据应该是静态的或缓慢移动的，以最大程度地减少复制工作量，并降低其过时的可能性。

• 属于同一分片映射的 Shardlet 应具有相同的架构。 SQL 数据库不强制实施此规则，但如果每个 shardlet 具有不同的架构，数据管理和查询将变得非常复杂。 而是为每个架构创建单独的分片映射。 请记住，属于不同 shardlet 的数据可以存储在同一分片中。

• 事务作仅支持分片中的数据，而不支持跨分片。 只要事务属于同一分片，事务就可以跨越 shardlet。 因此，如果业务逻辑需要执行事务，请将数据存储在同一分片中或实现最终一致性。

• 将分片靠近访问这些分片中的数据的用户。 此策略有助于降低延迟。

• 避免混合使用高度活跃和相对非活动分片。 尝试在分片之间均匀分布负载。 这可能需要对分片键进行哈希处理。 如果要异地定位分片，请确保哈希键映射到存储在靠近访问该数据的用户的分片中保存的 shardlet。

对 Azure 表存储进行分区

Azure 表存储是围绕分区设计的键值存储。 所有实体都存储在分区中，分区由 Azure 表存储在内部管理。 表中存储的每个实体都必须提供一个包含两部分的键，其中包括：

• 分区键。 这是一个字符串值，用于确定 Azure 表存储将放置实体的分区。 具有相同分区键的所有实体都存储在同一分区中。

• 行键。 这是一个字符串值，用于标识分区中的实体。 分区中的所有实体按此键按升序按词法排序。 每个实体的分区键/行键组合必须是唯一的，长度不能超过 1 KB。

如果将实体添加到具有以前未使用的分区键的表中，Azure 表存储会为此实体创建新分区。 具有相同分区键的其他实体将存储在同一分区中。

此机制有效地实施自动横向扩展策略。 每个分区都存储在 Azure 数据中心的同一服务器上，以帮助确保从单个分区快速检索数据的查询。

Microsoft已发布 Azure 存储 可伸缩性目标。 如果系统可能超出这些限制，请考虑将实体拆分为多个表。 使用垂直分区将字段划分为最有可能一起访问的组。

下图显示了示例存储帐户的逻辑结构。 存储帐户包含三个表：客户信息、产品信息和订单信息。

每个表都有多个分区。

• 在“客户信息”表中，数据根据客户所在的城市进行分区。 行键包含客户 ID。
• 在“产品信息”表中，产品按产品类别进行分区，行键包含端口号。
• 在“订单信息”表中，订单按订单日期进行分区，行键指定订单的接收时间。 所有数据都按每个分区中的行键排序。

为 Azure 表存储设计实体时，请考虑以下几点：

• 通过数据访问方式选择分区键和行键。 选择支持大多数查询的分区键/行键组合。 最有效的查询通过指定分区键和行键来检索数据。 可以通过扫描单个分区来完成指定分区键和行键范围的查询。 这是相对快的，因为数据以行键顺序保存。 如果查询未指定要扫描的分区，则必须扫描每个分区。

• 如果实体有一个自然键，则将其用作分区键，并将空字符串指定为行键。 如果实体包含由两个属性组成的复合键，请选择最慢的更改属性作为分区键，选择另一个属性作为行键。 如果实体具有两个以上的键属性，请使用属性的串联来提供分区键和行键。

• 如果使用分区键和行键以外的字段定期执行查找数据的查询，请考虑实现 索引表模式，或者考虑使用支持索引编制的其他数据存储，例如 Azure Cosmos DB。

• 如果使用单调序列（如“0001”、“0002”、“0003”）生成分区键，并且每个分区仅包含有限的数据量，则 Azure 表存储可以物理将这些分区组合在同一服务器上。 Azure 存储假定应用程序最有可能跨连续分区（范围查询）执行查询，并针对这种情况进行优化。 但是，此方法可能会导致热点，因为新实体的所有插入都可能集中在连续范围的一端。 它还可以减少可伸缩性。 若要更均匀地分散负载，请考虑对分区键进行哈希处理。

• Azure 表存储支持属于同一分区的实体的事务作。 只要事务不包含超过 100 个实体，并且请求的有效负载不超过 4 MB，应用程序就可以以原子单元的形式执行多个插入、更新、删除、替换或合并作。 跨多个分区的作不是事务性的，可能需要实现最终一致性。 有关表存储和事务的详细信息，请参阅 执行实体组事务。

• 请考虑分区键的粒度：

  • 对每个实体使用相同的分区键会导致在一台服务器上保留的单个分区。 这可以防止分区横向扩展，并将负载集中在单个服务器上。 因此，此方法仅适用于存储少量实体。 但是，它确实确保所有实体都可以参与实体组事务。

  • 为每个实体使用唯一的分区键会导致表存储服务为每个实体创建单独的分区，这可能会导致大量小型分区。 此方法比使用单个分区键更具可缩放性，但无法实现实体组事务。 此外，提取多个实体的查询可能涉及从多个服务器读取。 但是，如果应用程序执行范围查询，则对分区键使用单调序列可能有助于优化这些查询。

  • 跨实体子集共享分区键可以对同一分区中的相关实体进行分组。 可以使用实体组事务执行涉及相关实体的作，通过访问单个服务器可以满足提取一组相关实体的查询。

有关详细信息，请参阅 Azure 存储表设计指南 和 可缩放分区策略。

对 Azure Blob 存储进行分区

使用 Azure Blob 存储可以保存大型二进制对象。 如果需要快速上传或下载大量数据，请在方案中使用块 Blob。 对需要随机而不是串行访问部分数据的应用程序使用页 Blob。

每个 Blob（块或页）都保存在 Azure 存储帐户中的容器中。 可以使用容器对具有相同安全要求的相关 Blob 进行分组。 此分组是逻辑的，而不是物理的。 在容器中，每个 Blob 都有唯一的名称。

Blob 的分区键是帐户名 + 容器名称 + Blob 名称。 分区键用于将数据分区为范围，并且这些范围在系统中进行负载均衡。 Blob 可以分布在多个服务器之间，以便横向扩展对它们的访问，但单个 Blob 只能由单个服务器提供服务。

如果命名方案使用时间戳或数字标识符，则可能会导致流量过多，从而限制系统进行有效负载均衡。 例如，如果有使用时间戳（如 yyyy-mm-dd）的 blob 对象的日常作，则该作的所有流量都将转到单个分区服务器。 相反，请考虑使用三位数哈希为名称添加前缀。 有关详细信息，请参阅 分区命名约定。

写入单个块或页的作是原子作，但跨越块、页或 Blob 的作不是。 如果需要确保在跨块、页面和 Blob 执行写入作时保持一致性，请使用 Blob 租约来获取写入锁。

对 Azure 存储队列进行分区

使用 Azure 存储队列可以在进程之间实现异步消息传送。 Azure 存储帐户可以包含任意数量的队列，每个队列可以包含任意数量的消息。 唯一的限制是存储帐户中可用的空间。 单个消息的最大大小为 64 KB。 如果需要大于此值的消息，请考虑改用 Azure 服务总线队列。

每个存储队列在包含该队列的存储帐户中都有一个唯一的名称。 Azure 基于名称对队列进行分区。 同一队列的所有消息都存储在由单个服务器控制的同一分区中。 不同的队列可以由不同的服务器管理，以帮助平衡负载。 将队列分配给服务器对应用程序和用户是透明的。

在大型应用程序中，不要对应用程序的所有实例使用相同的存储队列，因为此方法可能会导致托管队列的服务器成为热点。 而是对应用程序的不同功能区域使用不同的队列。 Azure 存储队列不支持事务，因此将消息定向到不同的队列对消息传送一致性的影响不大。

Azure 存储队列每秒最多可以处理 2,000 条消息。 如果需要以大于此速率处理消息，请考虑创建多个队列。 例如，在全局应用程序中，在单独的存储帐户中创建单独的存储队列来处理在每个区域中运行的应用程序实例。

对 Azure 服务总线进行分区

Azure 服务总线使用消息代理来处理发送到服务总线队列或主题的消息。 默认情况下，发送到队列或主题的所有消息都由同一消息代理进程处理。 此体系结构可以限制消息队列的总体吞吐量。 但是，还可以在创建队列或主题时对队列或主题进行分区。 为此，可以将队列或主题说明 EnablePartitioning 属性设置为 true。

分区队列或主题分为多个片段，每个片段由单独的消息存储和消息中转站提供支持。 服务总线负责创建和管理这些片段。 当应用程序将消息发布到分区队列或主题时，服务总线会将消息分配给该队列或主题的片段。 当应用程序从队列或订阅接收消息时，服务总线会检查每个片段中是否有下一条可用消息，然后将其传递给应用程序进行处理。

此结构有助于在消息中转站和消息存储之间分配负载，提高可伸缩性和提高可用性。 如果一个片段的消息中转站或消息存储暂时不可用，服务总线可以从其余可用片段之一检索消息。

服务总线将消息分配给片段，如下所示：

• 如果消息属于会话，则 SessionId 属性具有相同值的所有消息将发送到同一片段。

• 如果消息不属于会话，但发送方已为 PartitionKey 属性指定了值，则具有相同 PartitionKey 值的所有消息将发送到同一片段。

  注释

  如果同时指定了 SessionId 和 PartitionKey 属性，则必须将其设置为相同的值，否则将拒绝消息。

• 如果未指定消息的 SessionId 和 PartitionKey 属性，但启用了重复检测，则将使用 MessageId 属性。 具有相同 MessageId 的所有消息将定向到同一片段。

• 如果消息不包含 SessionId、PartitionKey、 或 MessageId 属性，则服务总线会按顺序向片段分配消息。 如果片段不可用，服务总线将转到下一个片段。 这意味着消息传送基础结构中的临时错误不会导致消息发送作失败。

确定服务总线消息队列或主题是否或如何分区时，请考虑以下几点：

• 服务总线队列和主题是在服务总线命名空间的范围内创建的。 服务总线目前允许每个命名空间最多 100 个分区队列或主题。

• 每个服务总线命名空间对可用资源施加配额，例如每个主题的订阅数、每秒并发发送和接收请求数以及可建立的最大并发连接数。 这些配额记录在 服务总线配额。 如果期望超过这些值，请使用自己的队列和主题创建其他命名空间，并将工作分散到这些命名空间中。 例如，在全局应用程序中，在每个区域中创建单独的命名空间，并将应用程序实例配置为使用最近的命名空间中的队列和主题。

• 作为事务一部分发送的消息必须指定分区键。 可以是 SessionId、PartitionKey或 MessageId 属性。 作为同一事务的一部分发送的所有消息都必须指定相同的分区键，因为它们必须由同一消息中转站进程处理。 不能将消息发送到同一事务中的不同队列或主题。

• 分区队列和主题在空闲时无法配置为自动删除。

• 如果要构建跨平台或混合解决方案，则分区队列和主题当前不能与高级消息队列协议（AMQP）一起使用。

对 Azure Cosmos DB 进行分区

Azure Cosmos DB for NoSQL 是用于存储 JSON 文档的 NoSQL 数据库。 Azure Cosmos DB 数据库中的文档是对象或其他数据片段的 JSON 序列化表示形式。 除非每个文档必须包含唯一 ID，否则不会强制实施固定架构。

文档组织到集合中。 可以在集合中将相关文档组合在一起。 例如，在维护博客文章的系统中，可以将每个博客文章的内容存储为集合中的文档。 还可以为每个主题类型创建集合。 或者，在多租户应用程序中（例如不同作者控制和管理自己的博客文章的系统），可以按作者对博客进行分区，并为每个作者创建单独的集合。 分配给集合的存储空间是弹性的，可以根据需要收缩或增长。

Azure Cosmos DB 支持基于应用程序定义的分区键对数据进行自动分区。 逻辑分区 是存储单个分区键值的所有数据的分区。 共享分区键相同值的所有文档都放置在同一逻辑分区中。 Azure Cosmos DB 根据分区键的哈希分配值。 逻辑分区的最大大小为 20 GB。 因此，选择分区键是设计时的重要决策。 选择具有各种值甚至访问模式的属性。 有关详细信息，请参阅 Azure Cosmos DB 中的分区和缩放。

如果 Azure Cosmos DB 提供的分区机制不够，可能需要在应用程序级别对数据进行分片。 文档集合提供了一种用于在单个数据库中对数据进行分区的自然机制。 实现分片的最简单方法是为每个分片创建集合。 容器是逻辑资源，可以跨越一个或多个服务器。 固定大小的容器的最大吞吐量限制为 20 GB 和 10,000 RU/秒。 无限制的容器没有最大存储大小，但必须指定分区键。 使用应用程序分片，客户端应用程序必须将请求定向到相应的分片，通常是基于定义分片键的数据的某些属性实现自己的映射机制。

所有数据库都是在 Azure Cosmos DB 数据库帐户的上下文中创建的。 单个帐户可以包含多个数据库，并指定创建数据库的区域。 每个帐户还强制实施自己的访问控制。 可以使用 Azure Cosmos DB 帐户将分片（数据库内的集合）异地定位到需要访问它们的用户，并强制实施限制，以便只有这些用户可以连接到它们。

在决定如何使用 Azure Cosmos DB for NoSQL 对数据进行分区时，请考虑以下几点：

• Azure Cosmos DB 数据库可用的资源受帐户配额限制的约束。 每个数据库可以保存多个集合，并且每个集合都与控制该集合的 RU 速率限制（保留吞吐量）的性能级别相关联。 有关详细信息，请参阅 Azure 订阅和服务限制、配额和约束。

• 每个文档都必须具有一个属性，该属性可用于唯一标识在其保存的集合中的文档。 此属性不同于分片键，用于定义保存文档的集合。 集合可以包含大量文档。 从理论上讲，它只受文档 ID 的最大长度限制。 文档 ID 最多可为 255 个字符。

• 针对文档的所有作都在事务的上下文中执行。 事务的范围限定为包含文档的集合。 如果作失败，则会回滚它执行的工作。 虽然文档受作的约束，但所做的任何更改都受快照级隔离的约束。 此机制可以保证，如果创建新文档的请求失败，则同时查询数据库的其他用户将看不到随后删除的部分文档。

• 数据库查询的范围也限定为集合级别。 单个查询只能从一个集合中检索数据。 如果需要从多个集合中检索数据，则必须单独查询每个集合，并在应用程序代码中合并结果。

• Azure Cosmos DB 支持可编程项，这些项可以与文档一起存储在集合中。 其中包括存储过程、用户定义的函数和触发器（用 JavaScript 编写）。 这些项目可以访问同一集合中的任何文档。 此外，这些项在环境事务的作用域内运行（在触发器触发时针对文档执行的创建、删除或替换作），或者启动新事务（在作为显式客户端请求运行存储过程的情况下）。 如果可编程项中的代码引发异常，则会回滚事务。 可以使用存储过程和触发器来保持文档之间的完整性和一致性，但这些文档必须全部是同一集合的一部分。

• 要保存在数据库中的集合不太可能超过集合的性能级别定义的吞吐量限制。 有关详细信息，请参阅 Azure Cosmos DB中的 请求单位。 如果预计达到这些限制，请考虑在不同的帐户中的数据库之间拆分集合以减少每个集合的负载。

对 Azure AI 搜索进行分区

搜索数据的能力通常是许多 Web 应用程序提供的导航和浏览的主要方法。 它基于搜索条件的组合帮助用户快速查找资源（例如电子商务应用程序中的产品）。 AI 搜索服务通过 Web 内容提供全文搜索功能，包括提前键入、基于近匹配的建议查询和分面导航等功能。 有关详细信息，请参阅 什么是 AI 搜索？。

AI 搜索将可搜索内容存储为数据库中的 JSON 文档。 定义索引，这些文档中指定可搜索字段，并向 AI 搜索提供这些定义。 当用户提交搜索请求时，AI 搜索使用适当的索引来查找匹配的项目。

为了减少争用，AI 搜索使用的存储可以分为 1、2、3、4、6 或 12 个分区，每个分区最多可以复制 6 次。 分区数乘以副本数的乘积称为 搜索单位（SU）。 AI 搜索的单个实例最多可以包含 36 个 SU（一个具有 12 个分区的数据库仅支持最多 3 个副本）。

系统会为分配给服务的每个 SU 付费。 随着可搜索内容的量增加或搜索请求速率的增长，可以将 SU 添加到 AI 搜索的现有实例来处理额外的负载。 AI 搜索本身将文档均匀分布到分区中。 目前不支持手动分区策略。

每个分区最多可包含 1500 万个文档，或占用 300 GB 存储空间（以较小者为准）。 最多可以创建 50 个索引。 服务的性能因文档的复杂性、可用索引以及网络延迟的影响而异。 平均而言，单个副本（1 SU）应该能够每秒处理 15 个查询（QPS），不过我们建议使用自己的数据执行基准测试以获取更精确的吞吐量度量。 有关详细信息，请参阅 AI 搜索 中的服务限制。

你对 AI 搜索如何为每个服务实例对数据进行分区的控制有限。 但是，在全局环境中，可以通过使用以下任一策略对服务本身进行分区来进一步提高性能和降低延迟和争用：

• 在每个地理区域中创建 AI 搜索实例，并确保客户端应用程序定向到最近的可用实例。 此策略要求跨服务的所有实例及时复制对可搜索内容的任何更新。

• 创建两个 AI 搜索层：

  • 每个区域中的一个本地服务，其中包含该区域中用户最常访问的数据。 用户可以在此处定向请求，以获取快速但有限的结果。
  • 包含所有数据的全局服务。 用户可以在此处定向请求速度较慢但更完整的结果。

当正在搜索的数据中存在重大区域差异时，此方法最合适。

对 Azure Redis 缓存进行分区

Azure Redis 缓存在云中提供基于 Redis 键值数据存储的共享缓存服务。 顾名思义，Azure Redis 缓存旨在用作缓存解决方案。 它仅用于保存暂时性数据，而不用作永久数据存储。 如果缓存不可用，则使用 Azure Redis 缓存的应用程序应能够继续运行。 Azure Redis 缓存支持主要/辅助复制以提供高可用性，但目前将最大缓存大小限制为 53 GB。 如果需要超过此空间，则必须创建其他缓存。 有关详细信息，请参阅 Azure Redis 缓存。

分区 Redis 数据存储涉及在 Redis 服务的实例之间拆分数据。 每个实例构成单个分区。 Azure Redis 缓存将 Redis 服务抽象化在外观后面，并且不会直接公开它们。 实现分区的最简单方法是创建多个 Azure Redis 缓存实例，并将数据分散到其中。

可以将每个数据项与标识符（分区键）相关联，该标识符指定存储数据项的缓存。 然后，客户端应用程序逻辑可以使用此标识符将请求路由到相应的分区。 此方案非常简单，但如果分区方案发生更改（例如，如果创建了其他 Azure Redis 缓存实例），则可能需要重新配置客户端应用程序。

本机 Redis （而不是 Azure Redis 缓存）支持基于 Redis 群集的服务器端分区。 在此方法中，可以使用哈希机制在服务器之间均匀划分数据。 每个 Redis 服务器存储描述分区保留的哈希键范围的元数据，还包含有关其他服务器上的分区中哪些哈希键的信息。

客户端应用程序只需将请求发送到任何参与的 Redis 服务器（可能是最近的服务器）。 Redis 服务器检查客户端请求。 如果它可以在本地解析，它将执行请求的作。 否则，它会将请求转发到相应的服务器。

此模型是使用 Redis 聚类分析实现的，在 Redis 网站上的 Redis 群集教程 页上进行了更详细的介绍。 Redis 群集对客户端应用程序是透明的。 可以将其他 Redis 服务器添加到群集（并且可以重新分区数据），而无需重新配置客户端。

页面 分区：如何在 Redis 网站上的多个 Redis 实例之间拆分数据， 提供了有关使用 Redis 实现分区的详细信息。 本部分的其余部分假定你正在实现客户端或代理辅助分区。

在决定如何使用 Azure Redis 缓存对数据进行分区时，请考虑以下几点：

• Azure Redis 缓存不打算充当永久数据存储，因此，无论实现什么分区方案，应用程序代码都必须能够从不是缓存的位置检索数据。

• 经常一起访问的数据应保存在同一分区中。 Redis 是一个功能强大的键值存储，提供多个高度优化的机制来构建数据。 这些机制可以是下列机制之一：

  • 简单字符串（长度高达 512 MB 的二进制数据）
  • 聚合类型（如列表）（可充当队列和堆栈）
  • 集（已排序和无序）
  • 哈希（可以将相关字段组合在一起，例如表示对象中字段的项）

• 聚合类型使你可以将许多相关值与同一键相关联。 Redis 键标识列表、集或哈希，而不是它包含的数据项。 这些类型都可用于 Azure Redis 缓存，数据类型 页面在 Redis 网站上进行描述。 例如，在跟踪客户下订单的电子商务系统中，每个客户的详细信息都可以存储在使用客户 ID 进行键控的 Redis 哈希中。 每个哈希可以保存客户的订单 ID 集合。 单独的 Redis 集可以保存订单，再次结构化为哈希，并使用订单 ID 进行键控。 图 8 显示了此结构。 请注意，Redis 不实现任何形式的引用完整性，因此开发人员有责任维护客户和订单之间的关系。

图 8. Redis 存储中用于记录客户订单及其详细信息的建议结构。

• 可以通过将相关信息存储在同一数据库中的不同聚合中来实现垂直分区。 例如，在电子商务应用程序中，可以在一个 Redis 哈希中存储经常访问的产品信息，并在另一个哈希中存储不太频繁使用的详细信息。 这两个哈希都可以将同一产品 ID 用作密钥的一部分。 例如，可以对产品信息使用“product： nn”（其中，nn 是产品 ID），对详细信息使用“product_details：nn”。 此策略可帮助减少大多数查询可能检索的数据量。

• 可以重新分区 Redis 数据存储，但请记住，这是一项复杂且耗时的任务。 Redis 群集可以自动重新分区数据，但此功能不适用于 Azure Redis 缓存。 因此，在设计分区方案时，请尝试在每个分区中留出足够的可用空间，以允许随时间推移的预期数据增长。 但是，请记住，Azure Redis 缓存旨在暂时缓存数据，缓存中保存的数据可以有有限的生存期指定为生存时间（TTL）值。 对于相对可变的数据，TTL 可能较短，但对于静态数据，TTL 可能更长。 如果此数据卷可能填充缓存，请避免在缓存中存储大量长期数据。 可以指定逐出策略，以便在空间处于高级时导致 Azure Redis 缓存删除数据。

  注释

  使用 Azure Redis 缓存时，可以通过选择适当的定价层来指定缓存的最大大小（从 250 MB 到 53 GB）。 但是，创建 Azure Redis 缓存后，无法增加（或减小）其大小。

• Redis 批处理和事务不能跨越多个连接，因此所有受批处理或事务影响的数据都应保存在同一数据库中（分片）。

  注释

  Redis 事务中的一系列作不一定是原子的。 组成事务的命令在运行之前会进行验证和排队。 如果在此阶段发生错误，则会丢弃整个队列。 但是，成功提交事务后，排队的命令将按顺序运行。 如果任何命令失败，则只有该命令停止运行。 将执行队列中的所有上一个和后续命令。 有关详细信息，请转到 Redis 网站上的 事务 页。

• Redis 支持有限数量的原子作。 支持多个键和值的此类型的唯一作是 MGET 和 MSET作。 MGET作返回指定键列表的值集合，MSET作存储指定键列表的值集合。 如果需要使用这些作，MSET 和 MGET 命令引用的键值对必须存储在同一数据库中。

对 Azure Service Fabric 进行分区

Azure Service Fabric 是一个微服务平台，为云中的分布式应用程序提供运行时。 Service Fabric 支持 .NET 来宾可执行文件、有状态和无状态服务和容器。 有状态服务提供 可靠的集合，用于在 Service Fabric 群集中的键值集合中持久存储数据。 有关可靠集合中分区键的策略的详细信息，请参阅 azure Service Fabric 中可靠集合指南和建议。

后续步骤

• Azure Service Fabric 的 概述介绍 Azure Service Fabric。

• 分区 Service Fabric Reliable Services 提供有关 Azure Service Fabric 中的可靠服务的详细信息。

对 Azure 事件中心进行分区

Azure 事件中心 专为大规模数据流设计，并且分区内置于服务中，以实现水平缩放。 每个使用者只读取消息流的特定分区。

事件发布者只知道其分区密钥，而不知道事件要发布到的分区。 键与分区的这种分离使发送者无需了解有关下游处理的过多信息。 （也可以将事件直接发送到给定分区，但通常不建议这样做。

选择分区计数时，请考虑长期缩放。 创建事件中心后，无法更改分区数。

后续步骤

有关在事件中心中使用分区的详细信息，请参阅 什么是事件中心？。

有关可用性与一致性之间的权衡的注意事项，请参阅事件中心 中可用性和一致性。