gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 13:19:58 26 4
gpt4 key购买 nike

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

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

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

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

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

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

最佳答案

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

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

关于java - Gemfire 对碰撞和重复条目的抵抗力如何?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43607445/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com