要缓存的数据：
需要对生产和测试中的 Coherence 拓扑提出建议（与备份一起分发）
问题
我们不知道将完成多少次读取操作，该解决方案将被客户端使用，其中低响应时间至关重要（不仅仅是数据一致性）并且取决于每个用例。缓存将通过以固定频率轮询并填充缓存来从 DB 更新（因为缓存是数据主机，而不是使用缓存的系统）。
为 Coherence 调整 JVM 大小的经验法则是，假设 1 个备份，数据是堆的 1/3：1/3 用于缓存数据，1/3 用于备份，1/3 用于索引和开销。
调整大小的最大困难是没有很好的方法来估计索引大小。您必须尝试使用真实世界的数据并进行测量。
JDK 1.6 JVM 的经验法则是从 4GB 堆开始，因此您需要 75 个缓存服务器节点。有些人已经成功使用更大的堆（16GB），因此值得尝试。对于大堆（例如 16GB），您应该不需要 1/3 的开销，并且可以容纳超过 1/3 的数据。对于大于 16GB 的堆，垃圾收集器调优变得至关重要。
为了获得最佳性能，每个节点应该有 1 个核心。
服务器机器的数量取决于可管理性、容量（内核和内存）和故障的实际限制。例如，即使您有一台可以处理 32 个节点的服务器，当一台机器发生故障时，您的集群会发生什么？集群将是机器安全的（备份不在同一台机器上），但考虑到要移动到新备份的大量数据，恢复将非常缓慢。另一方面，75 台机器很难管理。
我已经看到 Coherence 对于 1K 对象放置（包括网络跃点和备份）的延迟为 250 微秒（不是毫秒）。因此，您正在寻找的插入和更新的数量应该是可以实现的。使用多个线程插入/更新进行测试，并确保您的测试客户端不是瓶颈。
还有一些“经验法则”：
1) 对于高可用性，三个节点是一个很好的最小值。
2) 在 Java 7 中，您可以使用更大的堆（例如 27GB）和 G1 垃圾收集器。
3) 对于 100GB 的数据，使用 David 的指南，您将需要 300GB 的总堆。在具有 128GB 内存的服务器上，这可以通过 3 台物理服务器来完成，每台运行 4 个 JVM，每个 27GB 堆（总共约 324GB）。
4) 索引内存使用量因数据类型和数量而异。最好用一个有代表性的数据集进行测试，无论有没有索引，看看内存使用的差异是什么。