羣集上的休眠L2高速緩存

Question

Q1： 我說得對，只有這個廠商支持羣集上的Hibernate L2高速緩存嗎？

• 秦始皇對Hibernate（COMERCIAL）
• SwarmCache（自2003年以來未公佈）
• 的JBoss Cache 1.x的
• JBoss緩存2

Q2： 是否有任何替代品休眠二級緩存？ （也許一些DB緩存？）

Answer 1

Q1。 EhCache與分佈式的Hibernate L2 Cache非常相似。 我們正在將此用於我們的項目。

---

Q2。幾個緩存是可能的。

• 所有的數據庫在內部都已經做了很多的緩存，所以不用擔心這個部分。

然而，隨着數據庫 緩存的問題是，它在物理上 數據庫服務器上，所以每個查詢 涉及網絡電話（延遲，帶寬 ..）。這就是應用程序 服務器上緩存的整個點 。

---

• Hibernate的二級緩存有一些細節：
  • 很容易與（無碼，少的配置）
  • 概念在實體層面的工作（這是非常細我們有時需要緩存更大的穀物，以減少數據庫請求），
  • 通過id或集合工作（例如，緩存默認情況下，查詢結果被停用，因爲我t在一般情況下不可能有用）。

---

• 當Hibernate的L2是不合適的，我們用同樣的Ehcache庫高速緩存的數據（也就是不完全的實體）。的使用情況例子：
  • 當一個表是大（記錄長度和數量），內存使用情況將不允許完全緩存，但緩存僅適用於所有記錄三個字段是好的。可能是這些字段是經常訪問的字段，或者是不可變的...
  • 當我們有很多的讀取訪問緩存，並且每個都會觸發一個計算（在L2緩存上）給定我們有的實體：計算結果可以存儲在緩存中。 （典型例子，其中計算需要來自其他表的細節，但細節未用於最終結果，因此緩存不存儲這些細節）
  • 當表中的實體按類別和我們希望一次請求並緩存一個類別，而不是一次一個實體的常規L2緩存策略。

在分佈式情況下，這往往 轉化成當他們 實體之一被修改的時間，這對我們來說是功能 邏輯（和必不可少的 性能失效一個 類別，否則我們會 必須使所有這些 實體無效;這是因爲高速緩存 使整個區域無效，或者是 特定對象，但在 之間必須l OOP這是不好的性能）

和其他人我敢肯定...

因此，這種情況下是不是數據庫密切相關，它通常不會保存我們的Hibernate實體。我們把它放在業務層（而不是數據訪問或Daos）中，直接提供給業務代碼。請注意，對我們來說，它不是透明緩存，而是調用顯式業務服務（負責該緩存：如果數據不存在，則根據需要加載它），以執行操作或傳遞值。

這個緩存中有趣的線程問題：因爲這個緩存被我們的100個Web線程訪問，所以它需要是線程安全的。您可能知道爲什麼線程安全值在每次調用時都是不可變的或克隆的（這通常是性能問題）。所以我們所有的業務緩存都使用不可變對象，並且性能非常好。

Answer 2

EhCache有一個分佈式模式，但我不確定這是否支持Hibernate。不過，我不明白爲什麼它不應該起作用。

由於某些特定的原因，您是否遺漏了JBossCache 3？第一季度銷售價格：

Answer 3

您也可以使用[的Infinispan（JBoss緩存的演進）作爲二級緩存提供！] [1]

[1]：見http://infinispan.blogspot.com/2009/10/infinispan-based-hibernate-cache.html

Answer 4

hibernate-redis LIB將是完美的選擇。這是一個基於Redis的緩存。

爲什麼選擇Redis？它的速度非常快，在雲中運行，並且有像AWS Elasticache這樣的現成雲解決方案，因此您無需自己管理它。