Gemfire 对碰撞和重复条目的弹性如何?

How resiliant is Gemfire to collisions and duplicate entries?

我正在为一个 Java 应用程序编写设计文档,其中两个冗余进程从消息队列中读取项目,我们希望它们都使用相同的密钥将项目存储到 gemfire 存储,目的是让多个应用程序 运行 连续查询处理这些项目,然后将结果存储到另一个 Gemfire 区域。

我刚刚开始了解 Gemfire,目前我没有能力设置多服务器测试台,所以我想在研究时问几个问题。

假设两个进程同时将项目存储在 gemfire 中,这会导致任何问题吗?

如果一个键被写入两次,该项目是否会被覆盖,我是否可能遇到任何问题(性能或其他)与锁定键?

如果我有一个连续查询 运行 该项目会匹配,我会在查询中得到两个 "hits"/(事件?)还是只有第一个会产生匹配?

如果我有 4 个进程使用相同的密钥向商店写入相同的项目,这会有什么不同?

如果要写入的区域已分区,则您概述的方案将正常工作。在这种情况下,只要在不同节点上制作对象副本所需的时间,就会锁定主键。这里的主要考虑因素是您的网络速度。第二次写入将覆盖第一次。至于这是否适合您的性能取决于您每秒流式传输的对象数量。

以下是一些可供考虑的备选方案: 1) 您可以仅在一个客户端上创建持久队列和 运行 CQ。如果客户端出现故障,您只需重新启动它,您仍然具有一致性。 2) 在服务器上创建分区 "transaction" 区域。在您的客户端上,将从您的 CQ 返回的对象放入 "transaction" 区域并将 CQ 时间戳添加为密钥的一部分。在 "transaction" 区域的异步事件侦听器中,更新目标区域并删除 "transaction" 区域中的对象。 3) 创建一个 "transaction" 分区区域,该区域与您的目标区域位于同一位置。创建一个函数 onRegion(partitionedTransactionRegion).withFilter(key).withArguments(object and CQ timestamp)。您的客户使用上述签名调用该函数。该函数检查 "transaction" 区域中是否已添加密钥 + 时间戳。如果是这样,请忽略该操作。如果不是,请在 "transaction" 区域中设置密钥(密钥 + CQ 时间戳)并更新您的目标区域。在 "transaction" 区域设置过期政策,在一小时、一天或您的偏好后过期。