数据网格性能并调整指南

数据网格有两个用于缓存、远程和嵌入的部署模型。与传统数据库系统相比，两种部署模型都允许应用程序在读取操作和更高吞吐量的情况下访问数据，同时提高写操作的速度。

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

图 1.1. 远程缓存部署模型

View larger image

数据网格处理位于持久存储中数据的所有应用程序请求。

通过使用在线缓存，Data Grid 使用缓存加载程序和缓存存储来操作持久性存储中的数据。

图 1.2. 线性缓存

View larger image

数据网格存储了应用程序从持久性存储检索的数据，从而减少了读取操作的数量到持久性存储，并延长后续读取的响应时间。

图 1.3. 侧边缓存

View larger image

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

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

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

图 1.4. 分布式缓存

View larger image

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

将会话外部化到数据网格将为您提供以下优势：

图 1.5. 会话外部化

View larger image

数据网格可在地理分散的数据中心和不同的云供应商中备份集群之间的数据。跨站点复制为数据网格提供全局集群视图和：

图 1.6. 跨站点复制

View larger image

数据网格包括许多可配置的组合，决定单个公式用于涵盖所有用例的性能指标。

数据网格性能和调整指南 文档的目的是提供关于使用案例和架构的详细信息，可帮助您确定数据网格部署的要求。

另外，请考虑以下适用于 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)

例如，您计划存储大小为 10KB 的 100万条目，并为每个条目配置三个所有者以供可用性。如果您计划为集群中的每个节点分配 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

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

Reads:Writes

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

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

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

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

数据保证

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

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

集群扩展

数据网格集群可以随着工作负载需求而横向扩展，以便更有效地使用 CPU 和内存等计算资源。要充分利用此弹性，您应该考虑如何扩展节点数量或降低对缓存容量的影响。

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

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

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

同步或异步复制

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

通过同步复制，Data Grid 在复制请求在备份节点上完成时通知原始节点。如果复制请求因为集群拓扑的变化而失败，数据网格会重试操作。当复制请求因为其他错误而失败时，Data Grid 会抛出异常。

通过使用异步复制，Data Grid 并不为复制请求提供任何确认。这会对应用程序产生同样的影响，因为所有请求都成功。但是，在 Data Grid 集群中，主要所有者具有正确的条目和 Data Grid，使其在将来某个时间点备份节点。如果主所有者崩溃，备份节点可能没有条目的副本，或者它们可能没有日期副本。

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

使用异步复制无法保证提高了写入吞吐量，因为异步复制限制节点可在任何时间处理的备份写入数（通过 JGroups 每发送顺序）。同步复制允许节点同时处理更传入的写操作，在某些情况下，在某些配置中，单个操作需要更长的时间才能完成，从而为您提供更高的吞吐量。

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

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

片段数量

数据网格将数据划分为多个片段，以便在集群间平均分配数据。即使分布片段也会避免过载单个节点，并使集群重新平衡操作更高效。

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

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

Number of segments = 20 * Number of nodes

Number of segments = 20 * Number of nodes

例如，集群为 30 个节点，您应该配置 600 个片段。为较大的集群添加更多片段通常是一个好主意，但此公式应该为您提供了适合您部署的数量。

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

更改片段的数量也可以导致数据崩溃，因此要小心谨慎，根据您从基准测试和性能监控收集的指标。

如果 Data Grid 不是数据的主要来源，则嵌入和远程缓存的性质是陈旧的。在规划、基准测试和调整数据网格部署时，为您的应用程序选择合适的缓存过时程度。

选择一个级别，以便您可以充分利用可用的 RAM，并避免缓存未命中。如果 Data Grid 没有在内存中的条目，则在应用程序发送读写请求时，调用 转到主存储。

缓存丢失的读取和写入延迟，但在许多情况下，主要存储的调用比 Data Grid 性能损失要高得多。其中一个例子是将关系数据库管理系统(RDBMS)卸载到数据网格集群。以这种方式部署数据网格可大大降低运行传统数据库的财务成本，以便在缓存中产生更高程度的陈旧条目。

通过使用 Data Grid，您可以为条目配置最大闲置和 lifespan 值，以维护可接受的缓存过时程度。

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

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

另外，您可以使用最大空闲过期来控制数据网格如何在集群中更新时间戳元数据。数据网格发送 touch 命令，以协调跨节点同步或异步的最大空闲过期时间。使用同步复制时，您可以根据首选一致性或速度选择"sync"或"async" touch 命令。

RAM 是一种昂贵的资源，通常仅限于可用性。数据网格允许您通过从内存中删除条目，来管理内存用量，为频繁使用的数据赋予优先级。

通过以下方法驱除数据网格缓存：

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

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

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

下图显示了数据网格运行的 JVM 进程的内存空间简图：

图 2.1. JVM 内存空间

View larger image

JVM 堆内存

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

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

off-heap 内存

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

非堆内存：

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

将 Data Grid 配置为与持久数据源交互会严重影响性能。这种性能损失源自于以下事实：更传统的数据源本质上要慢于内存中缓存。当调用超出 JVM 时，读取和写入操作将始终更长。根据您对使用缓存存储的方式，数据网格性能的降低是性能的偏移量，导致内存数据提供了通过访问持久性存储中的数据提供了偏差。

使用持久性存储配置数据网格部署也会带来其他好处，例如，允许您为正常集群关闭保持状态。您还可以将缓存中的数据溢出到持久性存储，并在内存中仅提供容量之外获得容量。例如，您可以在总计有 1,000万次条目，同时只保留内存中的 200万次条目。

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

传递和激活可能会导致数据网格对缓存中给定条目执行多个调用。例如，如果内存中不可用，Data Grid 会将它放回内存，即一个读取操作，以及从持久存储中删除操作。另外，如果缓存已达到大小限制，Data Grid 会执行另一个写入操作来传递新驱除条目。

保护您的数据并防止网络入侵是部署规划中最重要的方面。敏感的客户详细信息将泄漏开放互联网或数据泄漏，允许黑客公开机密信息对业务声誉的偏差。

考虑到这一点，您需要一个强大的安全策略来验证用户并加密网络通信。但您的数据网格部署性能有哪些成本？在规划过程中如何考虑这些问题？

身份验证

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

Encryption

在节点间通过加密集群传输数据时保护数据，并防止您的 Data Grid 部署不受 MITM 攻击。加入集群时，节点会在加入集群时执行 TLS/SSL 握手，使用额外的往返增加延迟。但是，当每个节点建立连接后，它会始终保持连接，假设连接永远不会空闲。

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

除了使用 TLSv1.3 外，对加密造成性能损失的唯一方式是配置数据网格运行的 JVM。对于使用 OpenSSL 库而不是标准 Java 加密的实例，可以更快地处理结果达 20%。

授权

基于角色的访问控制(RBAC)允许您限制对数据的操作，为部署提供额外的安全性。RBAC 是实现最小权限的策略，使用户访问在 Data Grid 集群中分发的数据具有最低权限。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 来处理这些事件的监听程序可减少数据网格可用的 CPU，并减慢所有其他操作的速度。

对于远程缓存，Data Grid 服务器使用内部流程来触发客户端通知。Data Grid Server 将事件从主所有者节点发送到注册侦听器的节点，然后再将其发送到客户端。数据网格服务器还包括一个后端机制，可在客户端监听器处理事件太慢时延迟写入操作以缓存缓存。

例如，如果您有 10 个客户端注册了可发出 10 个事件的监听程序，则数据网格服务器通过网络发送 100 个事件。

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

通过查询数据网格缓存，您可以分析和过滤数据以获取实时见解。例如，请考虑在线游戏，在某种程度上相互竞争。如果您要在任何一个时间使用前十个播放器实施领导板，您可以创建一个查询来找出哪个 play 是否有最多点，并将结果限制为最多十条：

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 配置为索引缓存会导致查询更快。如果没有索引，查询必须滚动到缓存中的所有数据，根据数据的类型和数量，按量级的排序来降低结果。

在启用索引时，会有可衡量的性能损失。但是，对您要索引的内容进行仔细的规划以及对要索引的了解，您可以避免面临风险的影响。

最有效的方法是将 Data Grid 配置为仅索引所需的字段。无论您存储 Plain Old Java 对象(POJO)还是使用 Protobuf 模式，您标注的更多字段都越长，使用数据网格构建索引所需的时间。如果您有一个带有五个字段的 POJO，但您只需要查询这两个字段，请不要配置 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

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

数据网格可以执行 ACID （原子、一致、隔离、可持久的）事务，以确保缓存状态一致。

事务是指数据网格在单个操作中出出的一系列操作。事务中所有写入操作都成功完成，或者全部失败。这样，交易可以一致地修改缓存状态，提供读取和写入历史记录，或者根本不修改缓存状态。

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

对于具有低产率的工作负载，两个或更多的交易可能无法同时写入同一密钥，而临时锁定提供了最佳性能。

数据网格在事务提交前获取对密钥的写入锁定。如果密钥有争议，则获取锁定所需的时间可能会延迟提交。另外，如果数据网格检测到冲突的写入，则它将回滚交易，应用程序必须重试，从而增加延迟。

对于具有高竞争率的工作负载，保守锁定可提供最佳性能。

当应用程序访问密钥时，数据网格获取对密钥的写入锁定，以确保其他事务无法修改密钥。事务提交在单一阶段完成，因为密钥已经被锁定。用多个关键交易锁定，会导致数据网格锁定密钥更长的时间，从而降低写吞吐量。

数据网格集群可能会遇到脑裂情形，因为集群中的节点子集相互隔离，并且节点之间的通信变得不连接。当发生这种情况时，在次要分区中的数据网格缓存进入 DEGRADED 模式，而大多数分区中的缓存仍可用。

数据网格还可允许在将集群重新加入时进行读取。通过允许应用程序访问（潜在的过时）数据来拒绝对条目的写入和可用性，此策略具有更均衡的选择。

默认情况下，数据网格不会尝试解决合并冲突，这意味着集群可以更早地返回健康状态，且在正常集群重新平衡之外没有性能损失。然而，在这种情况下，缓存中的数据会更有可能不一致。

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

在总体 CPU 和内存分配方面，执行跨站点复制的数据网格集群通常是"ymmetrical"。当您将跨站点复制考虑大小大小时，主要关注对群集之间的状态传输操作的影响。

例如，NYC 中的 Data Grid 集群离线，客户端在 LON 中切换到 Data Grid 集群。当 NYC 中的集群重新上线时，状态转移将从 LON 转移到 NYC。此操作可防止客户端进行过时的读取，但对集群收到状态传输的性能损失。

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

Active/Active 部署冲突解析

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

以下示例演示了如何并发写入会导致在 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)，数据网格为您提供处理并发写入选择跨站点合并策略。

就性能而言，数据网格用来解决冲突的合并策略需要额外的计算，但通常不会产生显著损失。例如，默认的跨站点合并策略使用字典比较，或"字符串比较"，该比较仅用几纳秒来完成。

数据网格还提供 XSiteEntryMergePolicy SPI 用于跨站点合并策略。如果配置数据网格来解决与自定义实施冲突，您应该始终监控性能来衡量任何负面影响。

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

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

一个无限的考虑因素是，长时间运行的进程可能会对正常的读写操作造成负面影响。因此，您必须持续监控部署并持续评估性能。

嵌入缓存

通过使用嵌入式缓存，数据网格提供两个 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 Server 注册自定义 Java 实施，并通过调用 Hot Rod 或使用 Data Grid Command Line Interface (CLI)来编程执行任务。您可以在一个数据网格服务器实例或集群中所有服务器实例上执行任务。

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

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

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

值得注意的是，最佳性能是连续过程，而非最终目标。当您的基准测试显示，您的数据网格部署已达到所需的性能水平时，您就无法期望这些结果已得到修复或始终有效。

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

在 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