使用EhCache，Spring和Hibernate驗證緩存方法

Question

我有一個實現套接字連接以讀取位置數據的應用程序。 每個頭寸都與資產相關。 流正在實時更新數百個資產的位置數據。 這是2個域對象的基本類表示形式：

public class Asset{
    long id;
    Set<Position> positions;
}


public class Position{
    long id;
    Double latitude;
    Double longitude;
    Date timestamp
}

現在，我希望遠程客戶端可以使用最近1天的位置數據進行輪詢。 將有數百個客戶對每種資產的頭寸數據的最后一天進行輪詢請求。 每項資產將每5秒更新一次位置數據。 要求是客戶端請求與實時更新的同步時間不得超過10秒。

這給數據庫帶來了巨大的負擔-這就是EHCache的來歷-也許...

更好的選擇（可疑！）是配置一個緩存，當套接字連接讀取任何新的資產和相關的頭寸時，會將它們存儲在其中。 此緩存將使超過一天前更新的所有資產過期，並負責定期（每分鍾左右）將新的資產和頭寸寫入數據庫。 遠程客戶端將訪問資產和位置數據的緩存。

我只是想對這種方法是否明智以及EHCache的哪些功能可以促進這種想法提供一些想法/建議。

非常感謝

Answer 1

這對於EhCache和Hibernate 查詢緩存 可能是一個很好的用例。 這是基本架構。 首先，為Position對象啟用二級緩存。 我認為它錯過了代表一對多關系的asset字段，但這並不重要。

我假設客戶端正在運行與此查詢類似的查詢：

SELECT p
FROM Position p
WHERE timestamp >= :timestamp
  AND asset = :assert

:timestamp參數表示最近的24小時（當前時間-24小時）。 您需要在此查詢上啟用cacheable查詢提示。

發生的事情是：客戶端使用一對(asset, timestamp)參數間接運行此查詢。 Hibernate嘗試在查詢緩存中找到該對的查詢結果，以簡化查詢緩存鍵。

如果查詢結果丟失，它將運行查詢並將結果放入查詢緩存中。 但它只會放置匹配的Position實例的ID，而不是實例本身。 下次某些客戶端要求使用同一對(asset, timestamp) ，Hibernate將在查詢緩存中找到結果。 然后，只有ID，它將在二級緩存中搜索Position實例。

如您所見，這種情況非常復雜，有幾個因素會影響整體成功：

• 有幾對不同的(asset, timestamp) ？ 大致：

。

86400 (number of different seconds in a day) times 
  number of different assets 

鍵和值必須適合緩存。 請記住，每個值都是Position ID的列表。 那有很多記憶。 您可以通過限制不同時間戳的數量來減少這種情況。 最近24小時如此重要嗎？ 可以在23到24小時之間嗎？ 這樣，您可以舍入時間戳記並減小鍵空間的大小（緩存大小）。

• 查詢緩存中按ID標識的所有Position實例引用都必須適合緩存。 這可能是巨大的。 但是否則，您將遇到N + 1問題，因為在從查詢緩存中獲取數據時，由於L2緩存中沒有Position實體，因此Hibernate將從ID中按ID執行隱式查詢。

• 緩存失效由Hibernate執行。 但是請記住，每次插入Position表都會使查詢緩存無效。 在您的情況下，不可能完全預熱緩存。

話雖如此，您應該嘗試在Hibernate中查詢緩存。 但是查詢緩存非常棘手，需要大量調整才能正確實現。

提示：如果內存不足，請嘗試將EhCache溢出到磁盤。 從未嘗試過，但是我相信從本地磁盤中獲取序列化的緩存值（尤其是在使用SSD時） 可能比緩存未命中和數據庫查詢快得多。