我们使用配置为将数据写入 Postgres 的 AEQ + AsyncCacheListener 将 Apache Geode 连接到 Postgres。在异步写入期间，我们提交要持久化的事件列表，然后异步插入这些事件。假设我有两个客户端应用程序调用processEvents 进行异步写入，并且两者都有一些共同的事件，这些事件违反了某些密钥。但是，在客户端调用processEvents 之后，控制权立即返回给客户端。在这种情况下，客户如何知道是否发生了某些问题？解决此问题的最佳做法是什么？
【问题讨论】：
标签： gemfire geode spring-data-gemfire spring-boot-data-geode
您所说的共同事件“违反某些关键”是什么意思？像主键或外键约束，或者其他一些数据库约束（例如唯一性、非空值等）？
处理冲突取决于从 Geode 插入或写入后端 (Postgres) 数据库的数据的重要性和性质，以及从需求和业务逻辑 POV 对应用程序的重要性。
如果 2 个（或更多）客户端应用程序正在写入相同的缓存/数据库条目/记录，那么肯定最终会发生某种类型的冲突，并且如何处理它取决于数据和执行的操作类型数据。
一般来说，在更接近发生违规的地点和时间（例如在 AsyncEventListener 本身内部）处理违规可能更可取或理想，因为那时您应该拥有大部分必要的信息（例如 DataAccessException、事件、附加信息）查询数据库的能力）来处理这种情况。
在 AEQ 监听器中，您可以根据应用程序确定的数据和操作采用不同的策略：
您可以使用 Geode 将存储在 AEQ 中的事件合并为相同的键，这样可以最大限度地减少冲突/冲突。
如果需要通知客户端（如客户端/服务器拓扑中的“客户端”），那么您可以将失败的事件写入另一个 Region，其中客户端注册一个 CQ，以便在写入条目时收到通知这（失败的事件）Region。然后，与 CQ 关联的客户端处理程序可以采取适当的操作，例如通知最终用户、刷新然后重试操作等。
鉴于初始写入的异步性质，您只能在发生违规时异步响应。这与响应式世界（即 onSuccess/onFailure 事件处理程序）没有什么不同。
因此，在这种情况下，我认为没有真正的“最佳实践”，而只有“建议”。例如，尽可能在接近实际发生违规的情况下处理情况，因为处理违规通常需要随时获得必要的信息，以便就正确的行动方案做出最佳的、知情的决定。
有时您可以自动恢复，有时您可能需要手动干预。最肯定的是，不要猜测。清楚地记录您的应用程序/系统（已配置）行为何时可以处理，何时不能处理。
在这种情况下，我认为没有通用的、1 尺寸适合所有解决方案。
我希望这能给你一些想法。
【讨论】：