實時匹配記錄

下面是我想要實現的：我通過蜂窩網絡發送一些數據包。我也在嗅探流量來檢查對這些數據包的響應。響應可能會在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

實時匹配記錄

回答

相關問題