Data Grid Performance and Sizing Guide

Data Grid 有两个用于缓存、远程和嵌入式的部署模型。这两种部署模型都允许应用程序访问比传统数据库系统相比，对写操作的读操作和更高吞吐量的数据访问延迟。

红帽建议用于大多数部署的服务器/客户端架构。使用远程缓存部署的时间要快得多，因为数据层与业务逻辑分开。Data Grid Server 还提供监控和可观察性和其他内置功能，以帮助您降低开发成本。

图 1.1. 远程缓存部署模型

View larger image

网格处理驻留在持久性存储中的所有数据的应用程序请求。

借助在线缓存，Data Grid 使用缓存加载程序和缓存存储来对持久性存储中的数据进行操作。

图 1.2. 在线缓存

View larger image

Data Grid 存储应用从持久性存储检索的数据，这可以减少对持久性存储的读取操作数量，并提高后续读取的响应时间。

图 1.3. 侧缓存

View larger image

使用侧缓存，应用程序控制如何从持久性存储将数据添加到 Data Grid 集群中。当应用程序请求条目时，会出现以下情况：

Data Grid 使用一致的哈希技术将每个条目的固定副本数存储在集群的缓存中。通过分布式缓存，您可以线性扩展数据层，增加节点加入的容量。

分布式缓存为数据网格集群添加冗余，以提供容错和持久性保证。Data Grid 部署通常配置与持久性存储的集成，以便为安全关闭并从备份中恢复来保留集群状态。

图 1.4. 分布式缓存

View larger image

Data Grid 可以为在红帽构建 Quarkus、Red Hat JBoss EAP、Red Hat JBoss Web Server 和 Spring 上构建的应用程序提供外部缓存。这些外部缓存独立于应用程序层存储 HTTP 会话和其他数据。

将会话外部化到 Data Grid 为您提供了以下优点：

图 1.5. 会话外部化

View larger image

Data Grid 可以在地理上分散的数据中心和跨不同云提供商运行的集群间备份数据。跨站点复制通过全局集群视图和：

图 1.6. 跨站点复制

View larger image

Data Grid 包括许多可配置的组合，用于决定涵盖所有用例的性能指标的单一公式。

Data Grid Performance and Sizing Guide 文档旨在提供有关用例和架构的详细信息，可帮助您确定数据网格部署的要求。

另外，请考虑以下适用于 Data Grid 的以下相关因素：

根据不同组合和未知外部因素的数量，提供满足所有 Data Grid 用例的性能计算。如果前面列出的任何因素都不同，则无法将一个性能测试与另一个测试进行比较。

您可以使用 Data Grid CLI 运行基本性能测试，该测试收集有限的性能指标。您可以自定义性能测试，以便测试结果可能会满足您的需要。测试结果提供基准指标，可帮助您确定数据网格缓存要求的设置和资源。

测量您当前的设置的性能，并检查它们是否满足您的要求。如果没有满足您的需求，请优化设置，然后重新衡量其性能。

规划数据网格部署涉及计算数据集的大小，然后减少正确数量的节点和 RAM 大小来保存数据集。

您可以使用这个公式粗略估算数据集的总大小：

Data set size = Number of entries * (Average key size + Average value size + Memory overhead)

Data set size = Number of entries * (Average key size + Average value size + Memory overhead)

分布式缓存中的数据设置大小

分布式缓存需要一些额外的计算来确定数据集大小。

在正常操作条件中，分布式缓存为每个键/值条目存储多个副本，它们等于您配置的 所有者数。在集群重新平衡操作过程中，一些条目有一个额外的副本，因此您应该计算 所有者 + 1 的数量，以允许该场景。

您可以使用以下公式来调整分布式缓存数据集大小的估算：

Distributed data set size = Data set size * (Number of owners + 1)

Distributed data set size = Data set size * (Number of owners + 1)

Distributed data set size <= Available memory per node * Minimum number of nodes

Distributed data set size <= Available memory per node * Minimum number of nodes

Planned nodes = Minimum number of nodes + Number of owners - 1

Distributed data set size <= Available memory per node * (Planned nodes - Number of owners + 1)

Planned nodes = Minimum number of nodes + Number of owners - 1

Distributed data set size <= Available memory per node * (Planned nodes - Number of owners + 1)

例如，您计划存储 100万个条目，每个规模为 10KB，并为每个条目配置三个所有者以实现可用性。如果您计划为集群中的每个节点分配 4GB RAM，您可以使用以下公式来决定数据集所需的节点数：

Data set size = 1_000_000 * 10KB = 10GB
Distributed data set size = (3 + 1) * 10GB = 40GB
40GB <= 4GB * Minimum number of nodes
Minimum number of nodes >= 40GB / 4GB = 10
Planned nodes = 10 + 3 - 1 = 12

Data set size = 1_000_000 * 10KB = 10GB
Distributed data set size = (3 + 1) * 10GB = 40GB
40GB <= 4GB * Minimum number of nodes
Minimum number of nodes >= 40GB / 4GB = 10
Planned nodes = 10 + 3 - 1 = 12

您可以将集群数据网格缓存配置为复制或分布式。

Read:Writes

考虑您的应用程序执行更多写入操作或更多读操作。通常，分布式缓存为写入提供最佳性能，而复制缓存则提供最佳读取性能。

要将 k1 放置到具有三个所有者的三个节点的分布式缓存中，Data Grid 写入 k1 两次。复制缓存中的相同操作意味着数据网格写入 k1 三次。每个写入复制缓存的额外网络流量量等于集群中的节点数量。在十个节点的集群上，复制缓存会导致流量增加，以便进行写入等。您可以使用带有多播的 UDP 堆栈来最小化流量。

要从复制缓存中获取 k1，每个节点都可以在本地执行读取操作。从分布式缓存中获取 k1，处理操作的节点可能需要从集群中的不同节点检索密钥，这会导致额外的网络跃点，并增加读取操作的时间。

热 Rod 客户端也可以使用接近缓存功能来在本地内存中保持频繁访问的条目，并避免重复读取。

数据保障

由于每个节点包含所有条目，因此复制缓存可提供比分布式缓存更多的数据丢失保护。在三个节点的集群上，两个节点可能会崩溃，且不会丢失复制缓存中的数据。

在相同的场景中，具有两个所有者的分布式缓存将会丢失数据。为了避免使用分布式缓存的数据丢失，您可以通过以声明性方式为每个条目配置更多所有者或 numOwners （） 方法来增加集群中的副本数量。

集群扩展

Data Grid 集群根据工作负载需求水平扩展，以便更有效地使用 CPU 和内存等计算资源。为了充分利用这种弹性，您应该考虑如何扩展或缩减节点对缓存容量的影响。

对于复制缓存，每次节点加入集群时，它都会获得数据集的完整副本。将所有条目复制到每个节点会增加节点加入并限制总容量所需的时间。复制缓存永远不会超过主机可用的内存量。例如，如果您的数据集的大小为 10 GB，则每个节点必须至少有 10 GB 可用内存。

对于分布式缓存，添加更多节点会增加容量，因为集群的每个成员仅存储了数据的子集。要存储 10 GB 数据，如果所有者数为 2，则每个节点有 8 GB 的可用内存，而无需考虑内存开销。加入集群的每个额外节点都会将分布式缓存的容量增加 5 GB。

分布式缓存的容量不受底层主机可用的内存量的限制。

同步或异步复制

当主所有者向备份节点发送复制请求时，数据网格可以同步或异步通信。

通过同步复制，数据网格会在备份节点上复制请求时通知原始节点。如果复制请求因为集群拓扑更改而失败，则数据网格会重试操作。当复制请求因为其他错误而失败时，Data Grid 会抛出客户端应用程序异常。

借助异步复制，Data Grid 不会为复制请求提供任何确认。这对应用程序的影响与所有请求都成功相同。但是，在 Data Grid 集群中，主所有者具有正确的条目，Data Grid 会将其复制到备份节点。如果主所有者崩溃，则备份节点可能没有条目的副本，或者可能没有日期副本。

集群拓扑更改也可以导致数据与异步复制不一致。例如，假设一个有多个主要所有者的 Data Grid 集群。由于网络错误或某些其他问题，一个或多个主要所有者会意外地使集群意外出现，因此 Data Grid 更新哪些节点是哪些部分的主要所有者。当发生这种情况时，有些节点理论上可以使用旧的集群拓扑，一些节点使用更新的拓扑。通过异步通信，这可能会导致一个较短的时间，其中 Data Grid 处理从以前的拓扑复制请求，并应用来自写入操作的旧值。但是，Data Grid 可以检测节点崩溃和更新集群拓扑更改，因为这种情况可能不会影响很多写入操作。

使用异步复制不能保证提高写入吞吐量，因为异步复制限制节点可在任何时间处理的备份写入数量（通过 JGroups per-sender 排序）。同步复制允许节点同时处理更多传入的写入操作，某些配置中可能会满足单个操作完成的时间，从而为您提供更高的吞吐量。

当节点发送多个请求以复制条目时，JGroups 会一次将消息发送到集群中其他节点的其余部分，这会导致每个原始节点只有一个复制请求。这意味着，Data Grid 节点可以与其他写入操作并行处理，从而从集群中的其他节点一个写入。

Data Grid 使用集群传输层中的 JGroups 流控制协议来处理对备份节点的复制请求。如果未确认的复制请求数量超过流控制阈值，使用 max_credits 属性设置（默认为 4MB），则对原始器节点上的写入操作会被阻断。这适用于同步和异步复制。

片段数

Data Grid 将数据划分为不同的片段，以便在集群间平均分配数据。即使片段分布也避免了过度加载单个节点，并使集群重新平衡操作更高效。

默认情况下，Data Grid 会为每个集群创建 256 个哈希空间片段。对于每个集群具有最多 20 个节点的部署，这个片段是理想的情况，不应更改。

对于每个集群具有超过 20 个节点的部署，增加片段的数量会增加数据的粒度，以便 Data Grid 可以更有效地在集群中分发数据。使用以下公式计算您应该配置的片段数：

Number of segments = 20 * Number of nodes

Number of segments = 20 * Number of nodes

例如，如果集群为 30 个节点，您应该配置 600 个片段。但是，为大型集群添加更多片段通常是一个不错的想法，但这个公式应该可让您了解适合您的部署的数量。

更改 Data Grid 创建片段的数量需要完全重启集群。如果您使用持久性存储，您可能还需要使用 StoreMigrator 工具更改片段数量，具体取决于缓存存储实施。

更改片段数量也可以导致数据损坏，因此您应该谨慎，并基于从基准测试和性能监控收集的指标。

如果 Data Grid 不是数据的主要来源，则嵌入式和远程缓存会完全过时。在规划、基准测试和调优您的数据网格部署时，为您的应用选择适当的缓存过时级别。

选择一个允许您最佳使用可用 RAM 并避免缓存丢失的级别。如果 Data Grid 在内存中没有条目，则当应用程序发送读取和写入请求时调用主存储。

缓存未命中会增加读取和写入的延迟，但在很多情况下，对主存储的调用比数据网格的性能损失要高得多。其中一个例子是将关系数据库管理系统(RDBMS)卸载到 Data Grid 集群。以这种方式部署数据网格大大降低了运行传统数据库的财务成本，因此，在缓存中容忍更高程度的陈旧条目有意义。

借助 Data Grid，您可以为条目配置最大空闲和寿命值，以保持可接受的缓存过时级别。

更高的过期值意味着条目保留在内存中较长，这会增加读取操作返回过时值的可能性。较低过期值意味着缓存中存在较少的过时值，但缓存丢失的可能性更大。

为了执行过期，Data Grid 会从现有的线程池中创建一个收据器。线程的主要性能考虑是在过期运行之间配置正确的间隔。较短的间隔执行更频繁的过期，但使用更多线程。

另外，在最大闲置过期时，您可以控制 Data Grid 如何在集群中更新时间戳元数据。Data Grid 发送 touch 命令，以协调同步或异步节点间的最大闲置过期时间。使用同步复制时，您可以选择 "sync" 或 "async" touch 命令，具体取决于您首选一致性还是速度。

RAM 是一个昂贵的资源，通常限制在可用性方面。通过从内存中删除条目，您可以管理内存用量，为常用数据赋予优先级。

驱除绑定数据网格缓存：

从驱除的性能影响源自在缓存大小达到配置的阈值时，数据网格需要计算的额外处理。

驱除也可以减慢读操作速度。例如，如果读取操作从缓存存储检索条目，Data Grid 会将该条目置于内存中，然后驱除另一个条目。如果使用 passivation，此驱除过程可能会包括将新被驱除的条目写入缓存存储。发生这种情况时，读取操作不会返回值，直到驱除过程完成为止。

默认情况下，Data Grid 将缓存条目存储在 JVM 堆内存中。您可以将 Data Grid 配置为使用非堆存储，这意味着您的数据会占用受管 JVM 内存空间之外的原生内存。

下图显示了运行 Data Grid 的 JVM 进程的内存空间：

图 2.1. JVM 内存空间

View larger image

JVM 堆内存

堆分为年轻而旧代，可帮助在内存中保持引用的 Java 对象和其他应用数据。GC 进程从无法访问的对象回收空间，在生成内存池中更频繁地运行。

当 Data Grid 将缓存条目存储在 JVM 堆内存中时，GC 运行可能需要更长的时间才能开始向缓存中添加数据。因为 GC 是一个密集型过程，所以更频繁地运行可能会降低应用程序性能。

off-heap 内存

off-heap 内存是 JVM 内存管理之外的原生可用内存。JVM 内存空间 图显示包含类元数据且从原生内存分配的 Metaspace 内存池。该图还代表了包含 Data Grid 缓存条目的原生内存部分。

off-heap 内存：

但是，一个缺点是 JVM 堆转储不显示存储在 off-heap 内存中的条目。

配置数据网格以与持久数据源交互可大大影响性能。这种性能损失源自于更传统的数据源本质上比内存缓存慢。当调用在 JVM 外部时，读取和写入操作始终会花费更长的时间。根据您使用缓存存储的方式，但数据网格性能的减少是性能的偏移，这比访问持久性存储中的数据提高。

使用持久性存储配置 Data Grid 部署也会带来其他好处，例如，您可以为安全集群关闭保留状态。您还可以将缓存中的数据溢出到持久性存储，并获得超过内存中可用容量。例如，您可以总计有十百万个条目，同时在内存中只保留 200万个条目。

Data Grid 以直写模式或 write-behind 模式为缓存和持久存储添加键/值对。由于这些编写模式对性能有不同影响，因此在规划数据网格部署时您必须考虑它们。

传递和激活可能会导致 Data Grid 为缓存中给定条目执行多个调用持久性存储。例如，如果一个条目在内存中不可用，Data Grid 会将它重新置于内存中，它是一个读取操作，以及从持久性存储中删除它的 delete 操作。另外，如果缓存达到大小限制，则 Data Grid 会执行另一个写入操作来传递新被驱除的条目。

保护您的数据并防止网络入侵是部署计划最重要的方面之一。敏感的客户详细信息会泄漏开放互联网或数据漏洞，允许黑客公开机密信息对业务声誉产生影响。

考虑到这一点，您需要可靠的安全策略来验证用户并加密网络通信。但是，您的数据网格部署性能的成本是什么？在规划期间，您应如何使用这些注意事项？

身份验证

验证用户凭证的性能成本取决于机制和协议。Data Grid 通过 Hot Rod 每一次验证凭据，同时可能针对通过 HTTP 的每个请求。

Encryption

加密集群传输保护数据，因为它在节点间传递并保护您的数据网格部署免受 MITM 攻击。在加入集群时，节点会执行 TLS/SSL 握手，这会通过额外的往返增加性能损失并增加延迟。但是，当每个节点建立连接时，它会永久保留连接，假设连接永远不会处于闲置状态。

对于远程缓存，Data Grid 服务器也可以加密与客户端的网络通信。就客户端与远程缓存之间的 TLS/SSL 连接的影响是相同的。协商安全连接需要更长的时间，且需要一些额外的工作，但一旦连接建立对加密的延迟并不是数据网格性能的问题。

除了使用 TLSv1.3 外，除了偏移加密的性能丢失的唯一方法是配置 Data Grid 运行的 JVM。Java 17 的 TLS 性能现在与原生实施相比。

授权

基于角色的访问控制(RBAC)可让您限制对数据的操作，为您的部署提供额外的安全性。RBAC 是为用户访问跨 Data Grid 集群分布的数据进行最低特权策略的最佳方法。Data Grid 用户必须具有足够级别的授权才能从缓存中读取、创建、修改或删除数据。

添加另一层安全以保护您的数据将始终具有性能成本。授权为操作添加了一些延迟，因为 Data Grid 在允许用户操作数据前，会根据访问控制列表(ACL)验证每个延迟。但是，对授权的性能的影响要低于加密，因此成本通常会平衡。

客户端监听程序会在 Data Grid 集群上添加、删除或修改任何数据时提供通知。

例如，每当给定位置上温度发生变化时，以下实现会触发事件：

@ClientListener
public class TemperatureChangesListener {
   private String location;

   TemperatureChangesListener(String location) {
      this.location = location;
   }

   @ClientCacheEntryCreated
   public void created(ClientCacheEntryCreatedEvent event) {
      if(event.getKey().equals(location)) {
         cache.getAsync(location)
               .whenComplete((temperature, ex) ->
                     System.out.printf(">> Location %s Temperature %s", location, temperature));
      }
   }
}

@ClientListener
public class TemperatureChangesListener {
   private String location;

   TemperatureChangesListener(String location) {
      this.location = location;
   }

   @ClientCacheEntryCreated
   public void created(ClientCacheEntryCreatedEvent event) {
      if(event.getKey().equals(location)) {
         cache.getAsync(location)
               .whenComplete((temperature, ex) ->
                     System.out.printf(">> Location %s Temperature %s", location, temperature));
      }
   }
}

将监听程序添加到 Data Grid 集群会为您的部署添加性能注意事项。

对于嵌入式缓存，侦听器使用与 Data Grid 相同的 CPU 内核。接收许多事件并使用大量 CPU 处理这些事件可减少 Data Grid 可用的 CPU，并减慢所有其他操作。

对于远程缓存，Data Grid 服务器使用内部进程来触发客户端通知。Data Grid Server 将事件从主所有者节点发送到注册侦听器的节点，然后再将其发送到客户端。Data Grid Server 还包括一种后端机制，如果客户端监听程序处理事件太慢，则延迟写操作缓存。

作为远程缓存的示例，如果您在一个侦听器中注册了十个客户端发出 10 个事件，则数据网格服务器会完全通过网络发送 100 个事件。

您可以使用自定义过滤器提供 Data Grid 服务器，以减少到客户端的流量。过滤器允许数据网格服务器首先处理事件，并确定是否将它们转发到客户端。

查询数据网格缓存可让您分析和过滤数据以获取实时见解。例如，假设一个在线游戏，其中 players在某种程度上相互竞争。如果您要在任意一个时间使用前十个播放器实施领导板，您可以创建一个查询来找出哪个 players 在任意一个时间都有最大点，并将结果限制为最多 10：

Query topTenQuery = playersScores
  .create("from com.redhat.PlayerScore ORDER BY p.score DESC, p.timestamp ASC")
  .maxResults(10);
List<PlayerScore> topTen = topTenQuery.execute().list();

Query topTenQuery = playersScores
  .create("from com.redhat.PlayerScore ORDER BY p.score DESC, p.timestamp ASC")
  .maxResults(10);
List<PlayerScore> topTen = topTenQuery.execute().list();

前面的示例演示了使用查询的好处，因为它可让您找到与可能数百万缓存条目匹配的十个条目。

但是，在性能影响方面，您应该考虑索引操作与查询操作之间的权衡。将 Data Grid 配置为索引缓存会导致查询更快。如果没有索引，查询必须滚动缓存中的所有数据，从而根据类型和数据量来减慢结果。

启用索引时，对写入有可测量的丢失。但是，在一些小心的规划和对要索引的内容有一定的了解，您可以避免最差的影响。

最有效的方法是将 Data Grid 配置为仅索引您需要的字段。无论您存储 Plain Old Java Objects (POJO)还是使用 Protobuf 模式，您注解的更多字段都需要更长的时间来构建索引。如果您有一个带有五个字段的 POJO，但您只需要查询两个字段，请不要将 Data Grid 配置为索引您不需要的三个字段。

Data Grid 为您提供了多个选项来调优索引操作。例如，Data Grid 存储索引与数据不同，请将索引保存到磁盘而不是内存。每当添加、修改或删除条目时，Data Grid 使用索引写入器与缓存保持索引同步。如果您启用索引，然后观察较慢的写操作，并考虑索引会导致性能下降，您可以在写入磁盘前将索引保留在内存缓冲区中更长的时间。这会更快地索引操作，并有助于减少写入吞吐量降低，但消耗更多内存。对于大多数部署，但默认的索引配置适合，且不会减慢写速度。

在某些情况下，可能无法对缓存进行索引，例如，对于需要频繁查询且不需要结果的写密集型缓存。它都取决于您要实现的内容。更快的查询意味着更快的读取速度，但会牺牲索引较慢的写操作。

您可以通过正确设置 maxResults 和 hit-count-accuracy 值来提高索引查询的性能。

SELECT field1, field2 FROM Entity WHERE x AND y

SELECT field1, field2 FROM Entity WHERE x AND y

驻留在分布式系统上的数据容易受到临时网络中断、系统故障或只是简单人为错误造成的错误。这些外部因素不可控制，但可能会给数据质量造成严重后果。数据损坏的影响范围从降低客户的满意度到导致服务不可用的昂贵系统协调。

Data Grid 可以执行 ACID (atomic、consistent、isolated、durable)事务，以确保缓存状态一致。

事务是 Data Grid caries 作为单个操作的操作序列。事务中的所有写入操作都成功完成，或者全部失败。这样，事务会以一致的方式修改缓存状态，提供读取和写入的历史记录，或者根本不修改缓存状态。

启用事务的主要性能问题是在具有一致数据集和增加降低写入吞吐量的延迟之间找到平衡。

对于具有低竞争率的工作负载，其中两个或更多个交易可能同时写入同一密钥，则最佳锁定提供了最佳性能。

在事务提交前，数据网格在键上获取写入锁定。如果键竞争，获取锁定所需的时间可能会延迟提交。另外，如果 Data Grid 检测到冲突的写入，那么它将回滚事务，应用程序必须重试，从而增加延迟。

对于具有高竞争率的工作负载，pessimistic locking 可提供最佳性能。

当应用程序访问密钥时，数据网格会在密钥上获取写锁，以确保没有其他事务可以修改密钥。事务提交在单个阶段完成，因为密钥已被锁定。带有多个关键事务的 pessimistic 锁定会导致 Data Grid 锁定密钥更长的时间，这可能会降低写入吞吐量。

数据网格集群可能会遇到脑裂的情况，其中集群中的节点子集相互隔离，并在节点间进行通信。当发生这种情况时，Data Grid 缓存在次版本中进入 DEGRADED 模式，而大多数分区的缓存仍然可用。

Data Grid 还可在将集群重新加入集群时进行读取。此策略是通过允许应用访问（可能过时的）数据拒绝写入条目和可用性，实现一致性的更平衡选项。

默认情况下，Data Grid 不会尝试解决合并冲突，这意味着集群会更快返回到健康状态，且除普通集群重新平衡之外不会有性能损失。然而，在这种情况下，缓存中的数据会更有可能不一致。

如果您配置合并策略，则数据网格修复分区所需的时间要长。配置合并策略会导致 Data Grid 从每个缓存检索条目的每个版本，然后解决以下的任何冲突：

执行跨站点复制的数据网格集群通常以整体 CPU 和内存分配为"symmetrical"。当您考虑跨站点复制大小时，主要问题是集群之间的状态传输操作的影响。

例如，NYC 中的 Data Grid 集群进入离线，客户端切换到 LON 中的 Data Grid 集群。当 NYC 中的集群恢复在线时，状态转移会从 LON 变为 NYC。此操作可防止客户端的过时读取，但对接收状态传输的集群有性能损失。

您可以在集群中分配状态传输操作所需的增加。但是，状态传输操作的性能影响完全取决于环境和因素，如数据集的类型和大小。

Active/Active 部署的冲突解析

当多个站点处理客户端请求时，Data Grid 会检测与并发写入操作冲突，称为 Active/Active 站点配置。

以下示例演示了并发写入在 LON 和 NYC 数据中心中运行的 Data Grid 集群冲突条目：

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

在 Active/Active 站点配置中，您不应该使用同步的备份策略，因为并发写入会导致死锁和丢失数据。借助异步备份策略(strategy=async)，Data Grid 为您提供了处理并发写入的选择跨站点合并策略。

在性能方面，Data Grid 用来解决冲突的合并策略需要额外的计算，但通常不会产生显著损失。例如，默认的跨站点合并策略使用字典比较或"字符串比较"，这只需要几个纳秒才能完成。

Data Grid 还为跨站点合并策略提供 XSiteEntryMergePolicy SPI。如果您确实配置 Data Grid 以解决与自定义实现冲突的冲突，您应该始终监控性能以量化任何负面影响。

分布式缓存的一个优点是，您可以利用各个主机的计算资源来更有效地执行大规模数据处理。通过在 Data Grid 上直接执行您的处理逻辑，您可以将工作负载分散到多个 JVM 实例中。您的代码还在 Data Grid 存储数据的相同内存空间中运行，这意味着您可以更快地迭代条目。

在对数据网格部署的性能影响方面，这完全取决于您的代码执行。更复杂的处理操作性能较低，因此您应该在 Data Grid 集群中运行的任何代码，并仔细规划。首先测试您的代码，并执行在较小的、示例数据集上运行的多个执行。收集一些指标后，您可以开始识别优化并了解您正在运行代码的性能影响。

一个确定的考虑是，长时间运行的进程可能会开始对正常读写操作产生负面影响。因此，您可以随时监控部署并持续评估性能。

嵌入式缓存

借助嵌入式缓存，Data Grid 提供两个 API，可让您在与数据相同的内存空间中执行代码。

如果要在单一节点、一组节点或特定区域中的所有节点上运行操作，那么您应该使用集群执行。如果要运行一个为整个数据集保证正确结果的操作，则使用分布式流是一个更有效的选项。

ClusterExecutor clusterExecutor = cacheManager.executor();
clusterExecutor.singleNodeSubmission().filterTargets(policy);
for (int i = 0; i < invocations; ++i) {
   clusterExecutor.submitConsumer((cacheManager) -> {
      TransportConfiguration tc =
      cacheManager.getCacheManagerConfiguration().transport();
      return tc.siteId() + tc.rackId() + tc.machineId();
   }, triConsumer).get(10, TimeUnit.SECONDS);
}

ClusterExecutor clusterExecutor = cacheManager.executor();
clusterExecutor.singleNodeSubmission().filterTargets(policy);
for (int i = 0; i < invocations; ++i) {
   clusterExecutor.submitConsumer((cacheManager) -> {
      TransportConfiguration tc =
      cacheManager.getCacheManagerConfiguration().transport();
      return tc.siteId() + tc.rackId() + tc.machineId();
   }, triConsumer).get(10, TimeUnit.SECONDS);
}

Map<Object, String> jbossValues =
cache.entrySet().stream()
     .filter(e -> e.getValue().contains("JBoss"))
     .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

Map<Object, String> jbossValues =
cache.entrySet().stream()
     .filter(e -> e.getValue().contains("JBoss"))
     .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

远程缓存

对于远程缓存，Data Grid 提供了一个 ServerTask API，它可让您在 Data Grid 服务器注册自定义 Java 实现，并通过通过 Hot Rod 调用 execute （） 方法或使用 Data Grid 命令行界面(CLI)来以编程方式执行任务。您只能对一个 Data Grid 服务器实例或集群中的所有服务器实例执行任务。

在调整远程数据网格集群时，您需要计算条目的数量和大小，但也需要计算客户端流量的数量。数据网格需要足够的 RAM 来存储您的数据，并有足够的 CPU 来及时处理客户端读取和写入请求。

有很多不同的因素会影响延迟并确定响应时间。例如，键/值对的大小会影响远程缓存的响应时间。影响远程缓存性能的其他因素包括集群每秒请求数、客户端数量以及对写入操作的读取操作比。

设置并配置部署后，开始对 Data Grid 集群进行基准测试，以分析和衡量性能。基准测试显示存在限制的地方，以便您可以调整您的环境并调优您的数据网格配置，以获得最佳性能，这意味着实现最低延迟和最高吞吐量。

值得注意的是，最佳性能是持续进程，而不是最终目标。当您的基准测试显示您的数据网格部署已达到所需的性能级别时，您无法期望这些结果是固定或始终有效的。

通过创建一个 operator 订阅并下载包含命令行界面(CLI)的 Hyperfoil 分发，在 Red Hat OpenShift 上设置 Hyperfoil。

在 Red Hat OpenShift 上实例化 Hyperfoil Controller，以便您可以使用 Hyperfoil 命令行界面(CLI)上传并运行基准测试。

使用 Hyperfoil 运行基准测试，为 Data Grid 集群收集性能数据。

Hyperfoil 使用 stats 命令以表格式运行基准测试的结果。

stats

[hyperfoil]$ stats
Total stats from run <run_id>
PHASE  METRIC  THROUGHPUT  REQUESTS  MEAN  p50  p90  p99  p99.9  p99.99  TIMEOUTS  ERRORS  BLOCKED