Веб-приложение Java: как реализовать методы кеширования?

Ваш вопрос состоит из нескольких отдельных вопросов. Начнем медленно. ServletContext - хорошее место, где вы можете хранить дескриптор вашего кеша. Но вы платите, имея кеш на каждый экземпляр сервера. Это не должно быть проблемой. Если вы хотите зарегистрировать кеш в более широком диапазоне, рассмотрите возможность регистрации его в JNDI.

Проблема с кешированием. По сути, вы получаете xml через веб-сервис. Если вы получаете доступ к этому веб-сервису через HTTP, вы можете установить на своей стороне простой HTTP-прокси-сервер, который обрабатывает кеширование xml. Следующим шагом будет кеширование разрешенного xml в своего рода кеш локальных объектов. Этот кеш может существовать на каждом сервере без каких-либо проблем. Во втором случае EHCache отлично справится со своей задачей. В этом случае цепочка обработки будет такой Client - http request -> servlet -> look into local cache - if not cached -> look into http proxy (xml files) -> do proxy job (http to webservice).

Плюсы:

• Локальный кеш для каждого экземпляра сервера, который содержит только объекты из запрошенных xmls
• Один http-прокси, работающий на том же оборудовании, что и наше веб-приложение.
• Возможность масштабировать веб-приложение без добавления новых http-прокси для файлов xml.

Минусы:

• Новый уровень инфраструктуры
• +1 точка отказа (http прокси)
• Более сложное развертывание

Обновление: не забывайте всегда отправлять HTTP-запрос HEAD в прокси, чтобы обеспечить актуальность кеша.

Вот пример кеширования с помощью EhCache. Этот код используется в нескольких проектах для реализации специального кэширования.

1) Поместите ваш кеш в глобальный контекст. (Не забудьте добавить слушателя в WEB.XML).

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;

public class InitializationListener implements ServletContextListener {    
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        ServletContext ctx = sce.getServletContext();
        CacheManager singletonManager = CacheManager.create();
        Cache memoryOnlyCache = new Cache("dbCache", 100, false, true, 86400,86400);
        singletonManager.addCache(memoryOnlyCache);
        cache = singletonManager.getCache("dbCache");       
        ctx.setAttribute("dbCache", cache );           
    }
}

2) Получите экземпляр кеша, когда он вам понадобится. то есть из сервлета:

cache = (Cache) this.getContext().getAttribute("dbCache");

3) Выполните запрос кеш-памяти непосредственно перед выполнением дорогостоящей операции.

        Element e = getCache().get(key);
        if (e != null) {
            result = e.getObjectValue(); // get object from cache
        } else {
            // Write code to create the object you need to cache, then store it in the cache.
            Element resultCacheElement = new Element(key, result);
            cache.put(resultCacheElement);

        }

4) Также не забудьте сделать недействительными кэшированные объекты, когда это необходимо.

Дополнительные образцы можно найти здесь

Вариант №1: используйте библиотеку кэширования с открытым исходным кодом, такую ​​как EHCache

Не реализуйте свой собственный кеш, если есть несколько хороших альтернатив с открытым исходным кодом, которые вы можете использовать и начать использовать. Реализация собственного кеша намного сложнее, чем думает большинство людей, и если вы точно не знаете, что делаете с потоками, вы легко начнете изобретать колесо и решать некоторые очень сложные проблемы.

Я бы рекомендовал EHCache, он находится под лицензией Apache. Вы захотите взглянуть на образцы кода EHCace.

Вариант 2. Используйте Squid

Еще более простым решением вашей проблемы было бы использование Squid ... Поместите Squid между процессом, который запрашивает данные для кеширования, и системой, выполняющей запрос: http://www.squid-cache.org/

После того, как я еще немного осмотрелся, кажется, что самый простой способ достичь того, что мне нужно (в рамках требований и приемлемых ограничений, описанных в вопросе), - это добавить мой объект кэширования в контекст сервлета и найти его (или передавая его) там, где это необходимо.

Я бы просто создал экземпляр загрузчика конфигурации из ServletContextListener, а в методе contextInitialized () я бы просто сохранил его в ServletContext с помощью ServletContext.setAttribute (). Затем его легко найти в самих сервлетах, используя request.getSession (). GetServletContext (). GetAttribute ().

Я полагаю, что это правильный способ сделать это без использования Spring или какой-либо другой инфраструктуры для внедрения зависимостей.

Bref, вы можете использовать эту готовую конфигурацию Spring ehcache

1- ehcache.xml: показать глобальную конфигурацию Ehcache.

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="./ehcache.xsd" updateCheck="false" monitoring="autodetect" dynamicConfig="true" name="myCacheManager">

    <!-- 
    see ehcache-core-*.jar/ehcache-fallback.xml for description of elements
    Attention: most of those settings will be overwritten by hybris
     -->
    <diskStore path="java.io.tmpdir"/>

</ehcache>

2- ehcache-spring.xml: создайте EhCacheManagerFactoryBean и EhCacheFactoryBean.

    <bean id="myCacheManager"  class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
        scope="singleton">
        <property name="configLocation" value="ehcache.xml" />
        <property name="shared" value="true" />

    </bean>

 <bean id="myCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean" scope="singleton">
        <property name="cacheManager" ref="myCacheManager" />
        <property name="cacheName" value="myCache" />
        <property name="maxElementsInMemory" value="1000" />
        <property name="maxElementsOnDisk" value="1000" />
        <property name="eternal" value="false" />
        <property name="diskPersistent" value="true" />
        <property name="timeToIdle" value="600" />
        <property name="timeToLive" value="1200" />
        <property name="memoryStoreEvictionPolicy" value="LRU" />
        <property name="statisticsEnabled" value="true" />
        <property name="sampledStatisticsEnabled" value="true" />
    </bean>

3. Внедрите bean-компонент «myCache» в свой бизнес-класс, см. Следующий пример, чтобы начать работу с получением и помещением объекта в ваш кеш.

@Resource("myCache")
private net.sf.ehcache.Cache myCache; 

@Resource("myService")
private Service myService; 

public byte[] getFromCache(final String code) 
{ 
// init Cache 
final StringBuilder builder = new StringBuilder(); 
 // key to identify a entry in cache map
final String key = code;
// get form the cache 
final Element element = myCache.get(key); 
if (element != null && element.getValue() != null) 
{ 
       return (byte[]) element.getValue(); 
} 

final byte[] somethingToBeCached = myService.getBy(code); 
// store in the cache
myCache.put(new Element(key, somethingToBeCached)); 

return somethingTobeCached; 

} 

У меня не было проблем с помещением экземпляра кешированного объекта в ServletContext. Не забудьте еще 2 варианта (область запроса, область сеанса) с методами setAttributes этих объектов. Все, что изначально поддерживается внутри веб-контейнеров и j2ee-серверов, хорошо (под хорошим я подразумеваю, что оно не зависит от производителя и без тяжелых j2ee-библиотек, таких как Spring). Мои самые большие требования - это чтобы серверы запускались за 5-10 секунд.

Мне действительно не нравятся все решения для кеширования, потому что их так легко заставить работать на локальном компьютере, и сложно заставить его работать на производственных машинах. EHCACHE, Infinispan и т. Д. Если вам не нужна репликация / распространение в масштабе кластера, тесно интегрированная с экосистемой Java, вы можете использовать REDIS (база данных NOSQL) или nodejs ... Подойдет все, что связано с интерфейсом HTTP. Особенно

Кэширование может быть действительно простым, и вот чистое решение java (без фреймворков):

import java.util.*;

/*
  ExpirableObject.

  Abstract superclass for objects which will expire. 
  One interesting design choice is the decision to use
  the expected duration of the object, rather than the 
  absolute time at which it will expire. Doing things this 
  way is slightly easier on the client code this way 
  (often, the client code can simply pass in a predefined 
  constant, as is done here with DEFAULT_LIFETIME). 
*/

public abstract class ExpirableObject {
  public static final long FIFTEEN_MINUTES = 15 * 60 * 1000;
  public static final long DEFAULT_LIFETIME = FIFTEEN_MINUTES;

  protected abstract void expire();

  public ExpirableObject() {
    this(DEFAULT_LIFETIME);
  }

  public ExpirableObject(long timeToLive) {
    Expirer expirer = new Expirer(timeToLive);
    new Thread(expirer).start();
  }

  private class Expirer implements Runnable {  
    private long _timeToSleep;
    public Expirer (long timeToSleep){
      _timeToSleep = timeToSleep;
    }

    public void run() {
      long obituaryTime = System.currentTimeMillis() + _timeToSleep; 
      long timeLeft = _timeToSleep;
      while (timeLeft > 0) {
        try {
          timeLeft = obituaryTime - System.currentTimeMillis();  
          if (timeLeft > 0) {
            Thread.sleep(timeLeft);
          } 
        }
        catch (InterruptedException ignored){}      
      }
      expire();
    }
  }
}

См. Эту ссылку для дальнейших улучшений.