设计一个系统，其中服务端点(可能是简单的servlet)必须每秒处理3K请求(数据将发布到http)。
这些请求将被存储到mysql中。
他们需要指导的关键问题是它们将占发布到此端点的重复数据的很大百分比。
我只需要将唯一的数据存储到mysql，那么您会建议我用什么来处理重复数据呢？
发布的数据将如下所示:
<root>
<prop1></prop1>
<prop2></prop2>
<prop3></prop3>
<body>
maybe 10-30K of test in here
</body>
</root>
我将编写一个对prop1，prop2，pro3进行哈希处理的方法，以创建唯一的哈希码(主体可以不同，但仍被认为是唯一的)。
我正在考虑创建某种并发字典，这些字典将在请求之间共享。
在的24小时内，他们复制发布数据的机会更大。因此，每隔x小时，我便可以从此字典中清除数据。
关于存储重复项的数据结构有什么建议吗？考虑到每秒3K请求，清除数据以及应该存储多少记录的事情将变得非常快。
注意:它们是将要发布的1万个不同来源，并且重复发生的机会仅发生于给定来源。意味着我可能有不止一个字典，可能是一组资料来散布的东西。这意味着，如果source1发布数据，然后source2发布数据，则重复的更改非常低。但是，如果source1在一天中发布100次，则重复的机会非常高。
注意:请暂时忽略将发布的数据保存到mysql的任务，因为这本身就是另一个问题，重复检测是我需要帮助的第一个障碍。
最佳答案
有趣的问题。
我可能会在这里看到某种HashMaps结构的HashMap，其中HashMaps的第一级将使用源作为键，第二级将包含实际数据(用于检测重复项的最小值)并使用您的hashcode函数进行哈希处理。对于实际的实现，可能会选择Java的ConcurrentHashMap。
这样，如果您需要将负载分配到多台计算机上，则还可以设置结构来根据来源对传入负载进行分区。
关于清除，我认为您必须测量像数据这样的生产的确切行为。您需要了解成功消除重复项后数据增长的速度以及如何在HashMaps中进行分布。凭借良好的分布和不太快的增长，我可以想象它足以偶尔进行清理。否则，LRU策略可能会很好。