我有一个简单的用例。我有一个系统，不允许对REST服务（有几十个实例）的重复请求。但是，由于数据存储配置和下游服务的复杂性，也很难防止。
所以我唯一可以防止重复＆＃34;交易＆＃34;是有一些集中的地方，我写一个请求数据的唯一哈希。每个REST端点首先检查新请求的散列是否已经存在，并且只有在没有这样的散列的情况下才会继续。
出于这个问题的目的，假设使用数据库约束无法做到这一点。
一种解决方案是在数据库中创建一个表，用于存储请求哈希值，并始终在继续请求之前写入此表。但是，我想要比这更轻的东西。
另一个解决方案是使用类似Redis的东西，然后在继续处理请求之前写入redis我的唯一哈希值。但是，我不想启动Redis集群并维护它等等。
我在考虑在每个应用实例中嵌入Hazelcast并在那里编写我独特的哈希。理论上，所有实例都将在内存网格中看到哈希，并能够检测重复请求。这解决了我的问题，即拥有比数据库更轻的解决方案，以及不必维护Redis集群的其他要求。
现在好了我的问题。将Hazelcast用于此用例是一个好主意吗？ hazelcast是否足够快以检测以毫秒或微秒为单位的重复请求？
如果请求1进入实例1，请求2进入实例2微秒。实例1向hazelcast写入请求的散列，实例2仅在millyseconds后检查hazelcast是否存在散列，是否会检测到散列？ hazelcast是否会及时在群集中传播数据？它甚至需要这样做吗？
在此先感谢，欢迎所有想法。
答案 0 :(得分：1)
Hazelcast绝对是这种用例的不错选择。特别是如果您只使用Map<String, Boolean>并仅使用Map::containsKey进行测试，而不是检索元素并检查null。放置元素时也应该放置TTL，这样就不会耗尽内存。但是，与Redis相同，我们建议将Hazelcast与独立群集一起用于“更大”的数据集，因为缓存元素的生命周期通常会干扰应用程序的其余部分并使GC优化变得复杂。运行Hazelcast embedded是一种选择，只有在运行时对应用程序进行认真考虑和测试后才能采用。