java - Gemfire 对碰撞和重复条目的抵抗力如何？

Question

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

我刚刚开始掌握 Gemfire，目前还没有能力设置多服务器测试台，所以我想在研究时问一些问题。

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

如果一个 key 被写入两次，该项目是否会被覆盖，并且我是否可能因 key 被锁定而遇到任何问题(性能或其他)？

如果我有一个连续的查询运行，该项目将匹配，我会在查询中得到两个“点击”/(事件？)还是只有第一个会生成点击？

如果我有 4 个进程使用相同的 key 向商店写入相同的项目，这会有什么不同？

Answer 1

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

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