红帽全球峰会2.3. 集群缓存模式
您可以将集群的 Data Grid 缓存配置为复制或分发。
- 分布式缓存
- 通过在集群中为每个条目创建较少的副本来最大化容量。
- 复制缓存
- 通过在集群中的每个节点上创建所有条目的副本来提供冗余。
Read:Writes
考虑您的应用程序是否执行更多写操作还是更多读取操作。通常，分布式缓存为写入提供了最佳性能，而复制缓存为读取提供最佳性能。
要将 k1 放置到具有三个所有者的三个节点的分布式缓存中，Data Grid 将 k1 写入 k1 两次。复制缓存中的同一操作意味着 Data Grid 写入 k1 三次。每个写入复制缓存的额外网络流量数量等于集群中的节点数量。在 10 个节点的集群中复制缓存会导致对写入的流量增加十倍。您可以使用带有多播进行集群传输的 UDP 堆栈来最小化流量。
若要从复制缓存获取 k1，每个节点都可以在本地执行读取操作。但是，若要从分布式缓存获取 k1，处理该操作的节点可能需要从集群中的不同节点检索密钥，这会导致额外的网络跃点并增加读操作完成的时间。
客户端智能和接近缓存
Data Grid 使用一致的哈希技术使 Hot Rod 客户端拓扑感知并避免额外的网络跃点，这意味着读取操作对分布式缓存的性能相同，因为它们对复制缓存具有同样的性能。
热 Rod 客户端也可以使用接近缓存功能在本地内存中保持频繁访问的条目，并避免重复读取。
分布式缓存是大多数数据平面服务器部署的最佳选择。您可以获得读写操作的最佳性能，以及集群扩展的参与。
数据保证
由于每个节点包含所有条目，复制缓存比分布式缓存提供更多数据丢失。在三个节点的集群上，两个节点可能会崩溃，且不会丢失复制缓存中的数据。
在这种情况下，具有两个所有者的分布式缓存将会丢失数据。为了避免使用分布式缓存进行数据丢失，您可以通过以编程方式为每个条目配置更多 所有者 来增加集群中的副本数量。
在节点失败时重新平衡操作
在节点失败后重新平衡操作可能会影响性能和容量。当节点离开集群时，Data Grid 会在剩余成员内复制缓存条目，以恢复配置的拥有者数。此重新平衡操作是临时的，但增加的集群流量会对性能造成负面影响。性能下降越大，节点会保留更多。当太多节点离开时，集群中保留的节点可能没有足够的容量来在内存中保留所有数据。
集群扩展
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
例如，对于 30 个节点的集群，您应该配置 600 个片段。为较大的集群添加更多片段通常是一个很好的想法，但此公式应让您了解正确的部署数字。
更改片段数据网格创建的数量需要完全重启集群。如果您使用持久性存储，您可能还需要使用 StoreMigrator 工具更改片段数量，具体取决于缓存存储实施。
更改片段数量还可能导致数据崩溃，因此您应该根据从基准测试和性能监控收集的指标谨慎，并谨慎操作。
Data Grid 始终在内存中的片段数据。当您配置缓存存储时，Data Grid 并不总是在持久性存储中分段数据。
它依赖于缓存存储实施，但尽可能为缓存存储启用分段。在迭代持久性存储中的数据时，分段缓存存储可提高数据中心性能。例如，对于基于 RocksDB 和 JDBC 字符串的缓存存储，分段可减少数据中心从数据库检索的对象数量。
