部署规划和大小指南

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

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

图 1.1. 远程缓存部署模型

View larger image

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

通过 in-line 缓存，Data Grid 使用缓存加载程序和缓存存储来对持久性存储中的数据进行操作。

图 1.2. 在线缓存

View larger image

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

图 1.3. 侧缓存

View larger image

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

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

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

图 1.4. 分布式缓存

View larger image

数据科学家可以为红帽构建的 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 性能考虑和调优指南 文档的目的是提供有关用例和架构的详细信息，可帮助您确定数据网格部署的要求。

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

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

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

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

规划 Data Grid 部署涉及计算您的数据集的大小，然后处理正确的节点数以及保存数据集的 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 的条目，每个条目的大小为 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

您可以将集群的 Data Grid 缓存配置为复制或分发。

Read:Writes

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

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

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

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

数据保证

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

在这种情况下，具有两个所有者的分布式缓存将会丢失数据。为了避免使用分布式缓存进行数据丢失，您可以通过以编程方式为每个条目配置更多 所有者 来增加集群中的副本数量。

集群扩展

Data Grid 集群随着工作负载需求水平扩展，以便更有效地使用计算资源，如 CPU 和内存。要充分利用这种技术的最大优势，您应该考虑如何扩展节点或缩减节点会影响缓存容量。

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

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

分布式缓存的容量不会与底层主机可用的内存量绑定。

同步或异步复制

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

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

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

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

使用异步复制不能保证写入吞吐量，因为异步复制会将节点可以随时处理的备份写入数量限制为可能发送的发送者数（通过 JGroups 每发送者排序）。同步复制允许节点同时处理更多传入的写入操作，在某些配置中，单个操作需要更长的时间完成，从而为您提供更高的吞吐量。

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

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

片段数

Data Grid 将数据分成网段，以在集群间平均分配数据。即使部分分布也会避免过载单个节点，并使集群重新平衡操作效率更高。

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

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

Number of segments = 20 * Number of nodes

Number of segments = 20 * Number of nodes

例如，对于 30 个节点的集群，您应该配置 600 个片段。为较大的集群添加更多片段通常是一个很好的想法，但此公式应让您了解正确的部署数字。

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

更改片段数量还可能导致数据崩溃，因此您应该根据从基准测试和性能监控收集的指标谨慎，并谨慎操作。

如果 Data Grid 不是数据的主要来源，嵌入式和远程缓存会按性质过时。在规划、基准测试和调优您的数据平面部署时，为您的应用程序选择适当的缓存过时性。

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

缓存丢失会增加读取和写入的延迟，但在很多情况下，对主存储的调用比 Data Grid 的性能损失要高得多。其中一个例子是将相关数据库管理系统(RDBMS)卸载到 Data Grid 集群。以这种方式部署数据中心可显著降低运行传统数据库的财务成本，从而在缓存中容忍更高级别的过时的条目。

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

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

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

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

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

驱除范围 Data Grid 缓存：

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

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

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

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

图 2.1. JVM 内存空间

View larger image

JVM 堆内存

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

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

离线内存

脱机内存是 JVM 内存管理之外的原生可用内存。JVM 内存空间 图显示包含类元数据并从原生内存分配的 Metaspace 内存池。图也代表了包含 Data Grid 缓存条目的原生内存部分。

离线内存：

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

配置数据仓库以与持久数据源交互可严重影响性能。这个性能损失来自于，传统数据源比内存缓存要慢得多。当调用超出 JVM 时，读取和写入操作总是需要更长的时间。但是，根据您使用缓存存储的方式，数据网格性能降低会降低性能降低，从而提高了内存数据在访问持久性存储中的数据。

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

Data Grid 添加键/值对，以便以 write-through 模式或 write-behind 模式缓存和持久性存储。由于这些写入模式对性能有不同影响，所以您必须在规划 Data Grid 部署时考虑它们。

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

保护您的数据并防止网络入侵是部署规划最重要的方面之一。敏感的客户详情会泄漏到开放互联网或数据被破坏，从而使黑客公开机密信息对业务造成影响。

考虑到这一点，您需要一个强大的安全策略来验证用户和加密网络通信。但是您的数据中心部署性能是多少？在规划过程中，您应该如何处理这些注意事项？

身份验证

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

加密

加密集群传输安全，因为它在节点间传递，并防止您的数据平面部署不受 MITM 攻击的影响。当加入集群时，节点会执行 TLS/SSL 握手，该集群会牺牲性能损失，并通过额外的往返增加延迟。但是，在每个节点建立连接后，它会永久保持连接，假设连接永不处于闲置状态。

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

除了使用 TLSv1.3 外，对加密的性能丢失的唯一方法是配置数据平面运行的 JVM。例如，使用 OpenSSL 库而不是标准 Java 加密可以更有效地处理结果，从而更快地获得 20%。

授权

基于角色的访问控制(RBAC)可让您限制对数据的操作，为部署提供额外的安全性。RBAC 是实现最小特权策略的最佳方法，供用户访问在 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 个事件，则 Data Grid Server 会在网络间发送 100 个事件。

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

查询数据平面缓存可让您分析和过滤数据以获得实时分析。例如，一个在线游戏，其中播放者以某种方式相互竞争。如果要在任何时间点上使用前十个播放器实现领导板，您可以创建一个查询来查找哪个播放者在任意时间点上具有最多点，并将结果限制为最多 10 个，如下所示：

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

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

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

但是，在性能影响方面，您应该考虑索引操作与查询操作所带来的权衡。将 Data Grid 配置为索引缓存可更快地进行查询。如果没有索引，查询必须滚动缓存中的所有数据，根据类型和数据数量，按 magnitude 的顺序减慢结果。

在启用索引时，对写入的性能有可测量的丢失。但是，由于一些小心的计划，并对要索引的内容有很好的了解，您可以避免影响最差。

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

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

在某些情况下，可能不对缓存进行索引，比如对于需要查询不经常查询的写密集型缓存，且不需要产生毫秒。它都取决于您要实现的功能。更快的查询意味着更快的读取速度，但会牺牲索引的较慢的写入成本。

SELECT field1, field2 FROM Entity WHERE x AND y

SELECT field1, field2 FROM Entity WHERE x AND y

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

数据中心可以执行 ACID （绿色、一致、隔离、持久）事务，以确保缓存状态一致。

事务是数据中心以单一操作形式进行的一系列操作。事务中的所有写入操作都成功完成，或者它们都失败。这样，事务会以一致的方式修改缓存状态，提供读取和写入的历史记录，或者根本不修改缓存状态。

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

对于争用率较低的工作负载，其中两个或多个事务可能无法同时写入同一密钥，因此最佳锁定可提供最佳性能。

Data Grid 在事务提交前在密钥上获取写入锁定。如果密钥争用，获取锁定所需的时间可能会延迟提交。另外，如果 Data Grid 检测到冲突的写入，它会回滚事务，应用程序必须重试它，增加延迟。

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

当应用程序访问它们以确保其他事务都不可修改密钥时，数据科学家在密钥上获取写入锁定。事务提交在单个阶段完成，因为密钥已经被锁定。通过多个关键事务进行模拟锁定会导致 Data Grid 锁定密钥更长的时间，这可以降低写入吞吐量。

Data Grid 集群可能会遇到脑裂情况，其中集群中的节点子集相互隔离，节点之间的通信也会被取消加入。当发生这种情况时，在次要分区中的 Data Grid 缓存进入 DEGRADED 模式，同时大多数分区中的缓存仍然可用。

数据中心还可以允许读取，同时将集群重新连接在一起。此策略是通过允许应用程序访问（潜在的）数据来拒绝对条目和可用性的写入来实现一致性选项。

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

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

执行跨站点复制的数据中心集群通常会"匿名"整个 CPU 和内存分配。当您考虑跨站点复制的大小时，主要问题是集群间的状态传输操作的影响。

例如，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 站点配置中，您不应该使用同步备份策略，因为并发写入会导致死锁并丢失数据。借助异步备份策略(policy=async)，数据科学家为您提供了处理并发写入的跨站点合并策略。

就性能而言，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，可让您通过 Hot Rod 调用 execute （） 方法或使用 Data Grid 命令行界面(CLI)以编程方式注册自定义 Java 实现。您只能在一个 Data Grid 服务器实例或集群中的所有服务器实例上执行任务。

当调整远程 Data Grid 集群的大小时，您需要计算条目的数量和大小，同时计算客户端流量的数量。Data Grid 需要足够的 RAM 来存储您的数据和 CPU，以便及时处理客户端读取和写入请求。

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

设置并配置部署后，开始基准测试您的 Data Grid 集群以分析和衡量性能。基准测试显示存在限制的位置，以便您可以调整您的环境并调整您的数据中心配置以获得最佳性能，这意味着达到最低延迟和最高吞吐量。

值得注意，最佳性能是一个持续的过程，而不是最终目标。当您的基准测试显示您的 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