实时匹配记录

下面是我想要实现的：我通过蜂窝网络发送一些数据包。我也在嗅探流量来检查对这些数据包的响应。响应可能会在10小时内出现。实时匹配记录

我发送的数据包都是唯一的（往返），我想知道匹配数据包和响应的最佳方式。

我可以创建一个hashmap，并将每个数据包实时发送出去，并在返回时将其与响应进行匹配。在这一点上，has map项或者停留在hashmap中或者被删除（在被响应之后）。

所以，现在的问题是：考虑到我们每分钟发送2000个数据包，最佳实现方法是什么？ hashmap足够强大吗？搜索时间怎么样？

来源

2011-08-19 goblinjuice

我不认为单独的HashMap足够健壮，因为它不是线程安全的。我会试试ConcurrentHashMap。

至于较大的数据量，寻找一些缓存实现 - 这些通常有能力溢出到磁盘，并有时间到期，所以你可以免费清理。

来源

2011-08-19 21:59:39

谢谢你检测这个。我正在使用Concurrent HashMap。说到缓存，我做了一些研究，并认为可以选择MongoDB。当然，当地图中的条目数量可能超过1000万个时（例如，每个100个字节），我们将不得不考虑其性能与Hashmaps相比的性能。 – goblinjuice

散列表一定会“足够强大”。在每分钟发送2000个数据包并假设平均响应时间为5小时的情况下，您可能有600,000个数据包未完成。假设你的设备有足够的内存来存放数据包，并且你分配了一个足够大的散列表（比如600,000，加载因子为0.75），那么查找速度会非常快。

查看javadoc的HashMap了解更多详情。

来源

2011-08-19 21:59:38

如果您有足够的内存，只要映射键的hashCode方法被正确编写并允许以尽可能少的冲突分配潜在的1,200,000个键，则应该没有问题。 HashMap是O（1）。

但是记忆可能是一个问题。在最糟糕的情况下，你的地图上会有1,200,000个条目。如果它们中的每一个都需要400字节（这并不多，但我不知道你的数据包包含什么），你已经需要460 MB。

来源

2011-08-19 22:00:18

服务器是在CentOS上运行的具有32 GB RAM的HP刀片式服务器， t认为记忆将是一个问题。我更关心HashMap查找花费的时间太长，但要感谢O（1）点。 – goblinjuice

HashMap是“健壮的”（就其意义而言）。另一个考虑是设备内存。让我们看看：10小时* 60分钟/小时* 2000包/分钟= 1.200.000。对于HashMap，这意味着至少2.400.00指针，在32位体系结构9.600.000字节。只是为了HashMap的结构，假设没有colisions（每个冲突额外4个字节）并且不包括数据本身的大小（键和值）。记忆将是一个问题。

与时间有关，它取决于equals（）和hashCode（）函数的多少，以及HashMap中碰撞的次数（碰撞次数==执行等于的次数，或多或少）。没有这些数据就无法计算。

来源

2011-08-19 22:01:39 SJuan76

实时匹配记录

回答

相关问题