本文探讨在单个 JVM 中运行两个 GemFire 客户端的限制，并提供验证服务端数据同步延迟的可靠替代方法——利用 GemFire 同步复制特性，通过测量 put 操作耗时直接反映跨节点数据一致性完成时间。
本文探讨在单个 jvm 中运行两个 gemfire 客户端的限制，并提供验证服务端数据同步延迟的可靠替代方法——利用 gemfire 同步复制特性，通过测量 `put` 操作耗时直接反映跨节点数据一致性完成时间。
GemFire（现为 VMware Tanzu GemFire）设计上不支持在同一 JVM 中并行运行两个独立的客户端缓存实例。根本原因在于：GemFire 的客户端运行时依赖全局单例资源（如 CacheFactory 内部状态、连接池管理器、序列化注册表及 JMX 代理），且其初始化过程未做类加载器隔离。即使尝试通过不同配置创建多个 ClientCache 实例，也会触发 IllegalStateException 或导致连接冲突、序列化异常或心跳干扰。官方文档与实践均明确建议——每个 JVM 应仅维护一个 ClientCache 实例。
因此，您提出的“为 Server1 创建 ClientA、为 Server2 创建 ClientB”的测试方案在技术上不可行，也无法准确反映 Active-Active 模式下的复制行为。
✅ 正确的验证思路：利用 GemFire 的同步复制机制
GemFire 的 REPLICATE 或 PARTITION 区域（启用 redundancy）默认采用同步复制策略：put(key, value) 方法阻塞返回，当且仅当数据已成功写入主副本 且 完成指定冗余副本（如 1 个备份）的持久化后，调用才结束。这意味着：
- put 耗时 = 主节点写入 + 网络传输 + 备份节点写入 + 确认返回的总延迟；
- 该耗时即为数据在集群内达到强一致性的实际时间窗口。
? 示例代码（测量同步复制延迟）：
ClientCache cache = new ClientCacheFactory()
.addPoolLocator("localhost", 10334) // 连接 locator，自动发现所有服务器
.set("log-level", "warning")
.create();
Region<String, String> region = cache
.<String, String>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
.create("testRegion");
// 测量同步复制耗时
long start = System.nanoTime();
region.put("testKey", "testValue");
long end = System.nanoTime();
double latencyMs = (end - start) / 1_000_000.0;
System.out.printf("Data replicated to all redundant copies in %.3f ms%n", latencyMs);⚠️ 注意事项：
- 确保 Region 配置启用了冗余（例如 PartitionAttributes 中设置 redudancy=1）；
- 使用 CACHING_PROXY 或 PROXY 客户端区域类型，避免本地缓存干扰测量；
- 关闭客户端日志级别（如设为 warning）可减少 I/O 开销对计时的干扰；
- 若需区分 Active-Active 与 Active-Passive，应检查服务端部署拓扑：GemFire 默认无主备角色，所有数据节点均可读写——只要 Region 类型为 PARTITION 或 REPLICATE 且 redundancy > 0，即为 Active-Active；而 Active-Passive 通常需借助外部负载均衡器或自定义故障转移逻辑实现，非 GemFire 原生模型。
总结：放弃多客户端方案，转而通过精确测量 put() 延迟来评估数据同步性能，既符合 GemFire 架构设计，又具备高准确性和可重复性。
